[devin-ai-integration]

What and why

Two bugs in the diagram panel's webview (editors/vscode/src/webview/diagram.ts), both reproduced with jsdom tests that drive the real panel script before the fix.

Stale focused neighbourhood after an edit. draw showed the new canvas (show → applySelection) before storing the rendering in last, so a focused node's neighbours were marked from the previous rendering. After an edit moved a relationship, the new canvas was marked with the old neighbours until ELK's auto layout resolved and redrew; where auto layout is unavailable, it stayed wrong. draw now stores last = result before showing the canvas; the empty-canvas and table branches are folded into the same if (layout !== undefined) so there is one point of order.

Relations list counting edges the canvas never draws. The canvas hides an edge whose end is under a collapsed owner (PlacedNode.hidden → PlacedEdge.hidden in layout.ts), but showRelations/countRelations counted every edge of the RenderResult, so the list named kinds and totals that were not on the canvas.

Correct count, from the panel's design: the Relations list is the panel's hide-kinds filter, so it lists each kind the canvas has with how many edges there are (and N of M related for the focused node), a kind the filter hides included — the filter must say what it hides, which is why relatedByKind always counted hidden kinds. An edge at a node folded under a collapsed owner is different: no filter setting can draw it, so it is neither listed nor counted, and a kind with only such edges does not appear. The folded case is now one predicate, folded(placed, edge) in layout.ts, used by routeEdge for PlacedEdge.hidden (what the canvas skips) and by the new listedEdges(layout) (what the list counts). showRelations/countRelations take the CanvasLayout rather than the RenderResult, and relatedByKind takes the edge list to count.

Behaviour changes: a kind whose only edges are at folded nodes is no longer listed, and totals exclude folded edges.

Overlap: #1330 adds the jsdom harness for the panel script and src/markup.ts; the harness is shared, so its head is merged into this branch as a merge commit — first f26e19977, then d18b5e4f4 and dd250071b, which fix the two review findings raised here on that code (the only conflicts were both branches appending tests to diagram.test.ts, resolved by keeping both sets over one harness). #1335 dry-merged clean on top; both have since landed on develop, which is merged in. The branch fix/webview-collapsed-ports removes the webview's own fold of a collapsed owner's ports; it is behind develop and has no PR, and it did not render under these tests, so this change does not depend on it — once that lands, folded simply never holds for a port.

How it was verified

• editors/vscode: npm ci, npm run typecheck, npm run build, npm test — 383 pass, 0 fail (there is no lint script in this package).
• New tests in src/webview/diagram.test.ts, both failing on develop and passing here:
  • a focused node's neighbourhood follows an edit that moves its relationship — on develop: the canvas drawn for the edit marks a's new neighbour c: actual ['a','b'], expected ['a','c'].
  • the Relations list counts the edges the canvas draws under a collapsed owner — on develop: the list names the kinds the canvas draws: actual ['connection','dependency'], expected ['dependency'].
• python3 scripts/changelog.py check, go build ./..., go vet ./..., gofmt -l . (empty) — no Go change.
• Dry merges: fix(vscode): apply a routing change made during a drag when the drag settles #1330 conflicted on diagram.test.ts (resolved by the merge commit above); fix(vscode): sort the diagram panel's relationship kinds with an explicit code-unit comparator #1335 clean before and after that merge.

Native VS Code, develop f9f6d953f vs this branch

Both VSIXs built with npm run build -- --production + vsce package, installed into an isolated VS Code profile with a freshly built sysml-lsp.

Relations list under a collapsed owner. part a { port p; }, part b;, connection hiddenLink connect a.p to b;, binding visibleLink bind a = b;, an interconnection view with metadata Layout about a { collapsed = true; }; zero Problems. The canvas draws the binding only.

Before — lists the undrawn connection 1	After — lists only binding 1

On the branch, focusing a shows 1 of 1 related; unticking binding removes the edge and keeps its count; ticking it restores the edge:

Focused neighbourhood after an edit. With a focused, connection link connect a to b; edited to connect a to c; and saved. On a small model develop's stale frame lasts only until ELK redraws and was not capturable; with 601 exposed parts (over the panel's auto-layout cutoff) it is:

Before — new a–c edge drawn, b still highlighted, c dimmed	After — c highlighted, b dimmed

Checklist

• npm test, npm run typecheck, go build, go vet, gofmt -l pass locally
• Tests added or updated for the change
• Documentation extended where it already covers the surface (none covers the Relations list's counts)
• Changelog entry added as changes/unreleased/diagram-panel-focus-after-edit.fixed.md
• baselines regenerated and make docs-counts run if a gate count moved (none moved)
• No internal work-item labels in the body, docs, or changelog

Link to Devin session: https://nasa-jpl-demo.devinenterprise.com/sessions/b94cef1a8c024e98b730a806a001118d
Open in Devin Desktop: https://nasa-jpl-demo.devinenterprise.com/desktop/session/b94cef1a8c024e98b730a806a001118d?variant=devin
Requested by: @HuiJun

[devin-ai-integration]

I'll fix CI failures and address comments from users with write access. I'll skip comments containing "(aside)".

• Disable automatic comment, CI, and merge conflict monitoring