[endrix]

Phase 4b of the declutter plan, second half. Stacked on #122 (it uses the source-files.ts helpers that PR introduces); the base moves to main once #122 lands.

Six transports, one

Each of these spawned the sidecar, wrote { file, op, args } on stdin and parsed stdout with its own wording, its own deadline and its own idea of an empty answer:

caller	before	now
SidecarInvoker.invokeSidecar (every diagram edit)	own copy, 60 s default	invokeSidecar({ command, file, op, args })
invokeSidecarOp (chat edit backend, registry tools, capabilities, openability's sibling)	own copy with PYTHONPATH from the package root	thin wrapper, pythonPackageRoot: true
exportWorkflowGraph (chat exportGraph)	own copy, returned the graph or undefined	deleted; exportGraph sends the export op through invokeSidecarOp and reads diagnostic.graph
tryLoadGraphFromSidecar (model source)	own copy with the graph-load deadline and the timeout hint	invokeSidecar({ ..., timeoutMs, pythonPackageRoot: true }), then the same graph handling
probeDiagramOpenability	own copy, 20 s, read the last stdout line	invokeSidecar({ ..., timeoutMs: 20 s }); ok → true, status: 'error' → false, else unknown
sidecar.send command	own copy	invokeSidecar(...) → { ok, message }

sidecar-transport.ts never throws; it describes a child that could not start, timed out or exited non-zero with describeChildFailure plus the op, carries stderr, code (from diagnostic.code) and timedOut, and reads the last non-empty stdout line, so a sidecar that logs above its answer is still understood (the openability probe did this; the other five would have failed on the log line). The diagram's own edits still run without the package-root cwd/PYTHONPATH, as before; the requests that import the file (export, chat edits) keep it.

One graph-export default

All four sidecars answer exportGraph (wfpy and calpy alias it to their older names; hdl and ndf accept all three). The model source used to pick exportNetworkGraph or exportWorkflowGraph by acquisition strategy and ignore the product's exportOp (sv says exportModuleGraph and only worked through hdl-sidecar's aliases); registry tools and the chat defaulted to exportWorkflowGraph. Now: SidecarRuntimeConfig.exportOp is filled from the profile input, and every sender uses exportOp ?? DEFAULT_EXPORT_OP ('exportGraph').

What the review made of it

• A non-zero exit lost the sidecar's stderr from the message. The message is now what describeChildFailure says (command and stderr) plus the op, for every failure kind; failure: 'start' | 'timeout' | 'exit' | 'rejected' | 'invalid-json' says which, and the model source prefixes the command only where the message does not already carry it.
• A pretty-printed answer was refused by last-line parsing. The whole output is parsed first, the last line second.
• The probe took an empty answer for yes. ok with a response is yes; status: 'error' is no; nothing is unknown, as before. The dead payload object and the catch around a call that never throws are gone.
• The per-caller pythonPackageRoot flag kept two environments for one sidecar. Every request now runs from the file's package root with it on PYTHONPATH, the diagram's own edits included; stated in the changelog.
• DEFAULT_EXPORT_OP lives in sidecar-transport.ts (re-exported by sidecar-graph-export.ts), and the profile's literal uses it.

Tests

sidecar-transport.test.ts mocks the child process and pins the request line, last-line parsing, the empty answer, a rejected request with its code, exit/timeout/spawn failures with stderr, the deadline, and that nothing throws. chat-edit-backend.test.ts asserts the export through invokeSidecarOp; two characterization tests now expect exportGraph. Typecheck 5/5, neutrality 5/5, toolkit 336 with the known local wizard timeouts (green alone, green in CI).

https://claude.ai/code/session_01EToj6RJRMSSHQiqGNMU9wv