[endrix]

Summary

A product whose diagram is a specification wants to paint the report its tool makes about it (which requirements are covered, which are not) the way a run paints its progress. The platform had half of it: the execution overlay's publish(sourceUri, states) and a states field on its webview payload. Nothing sent published states to a diagram, nothing drew them, and the only way to reach the overlay was a run driver, which assumes a workflow runtime's run, stream and artifacts.

• Published states are drawn. Each change goes to the webview as the whole set, over the ungated path the events use, and again when an editor registers for the source. The client puts the run overlay's own classes on the nodes (running the turning ring, succeeded green, failed red, idle nothing) with a GLSP feedback command that matches against each model it is applied to, so the states outlive a save and a relayout and follow a view change in place. The registry keys states through the replay window's URI canonicalization.
• wf:graphNodeId. The diagram names a node after its label, so a state naming the producer's id matched nothing: every node now keeps the id its graph document gave it, and a state may name either. (feat/panel-links adds the same constant and line for its #<id> links; whichever merges second resolves a one-line overlap.)
• DiagramProfile.statusSource: a label, a show and a clear command, and collect(file) returning ExecutionNodeState[]. The platform registers the commands (they take the diagram's URI, as an editor-title menu passes it, or act on the active diagram), offers "Show " and "Clear " on the canvas's context menu (derived into clientBehavior.statusSource, like chatBackend), and publishes what collect answers into the overlay a run driver gets as DiagramRunHost.overlay. No run driver is needed. A failure is reported and changes nothing; a Clear wins over a Show still collecting; two Shows share one collect.
• SidecarProfileInput.statusSource: the same with collect(file, cli), where cli(args) runs the configured CLI in the file's folder with the graph-load deadline and resolves to its stdout parsed as JSON, whatever the exit code (a CLI that speaks JSON reports its own failures there).
• Neutral: the platform names no report; the label and the mapping are the product's.
• Tests: status-source.test.ts (12), execution-overlay-states.test.ts (5), diagram-editor-provider-status-source.test.ts (2), execution-states.test.ts (10), status-source-menu.test.ts (6), graph-node-id.test.ts (2), cli-status-source.test.ts (8, against a real child process). The container-parity baseline gains the menu provider, its action handler and the feedback command. CHANGELOG and README entries.

Plan item N8 of the ndf-ide plan (phase 4, the coverage overlay). Independent of #90–#99: based on main, and needs none of them. The ndf-ide shell maps ndf report coverage onto it. Drawn headlessly on a real specification (PicoRV32, trap.md): the unverified contract red, the verified one green, a TBD question with the ring.

Test plan

• npm run typecheck, npm run check:neutrality
• diagram-server suite (364)
• diagram-client suite (278)
• extension-core suite (327, 1 skipped)
• sidecar-toolkit suite (304). Under heavy machine load a few variant-node-create-wizard cases, which take 4 to 5 s of a 5 s budget and import nothing this changes, timed out intermittently; green on the final run.
• Live in VS Code: Show from the editor title and from the canvas's context menu paints the nodes; Clear takes them off; the states survive a save and a view change in place, and come back on a reopened editor

https://claude.ai/code/session_01E8WfqKknDNN6xpNVcJL5K8