Update Versions

[github-actions]

Changepacks

devup-mcp@0.12.0 → 0.13.0 - crates/devup-mcp/Cargo.toml

Minor

• Several devup-mcp processes on one machine now share the Devup Bridge plugin. Only one can hold the port the plugin's manifest allows (ws://localhost:1993), and one devup-mcp per MCP client session is normal, so every process but the first used to report listening: false and could read Figma only through the metered direct path - with a plugin attached and serving, the only remedy was to kill another session's process. The process holding the port is now the host and the others relay through its new /relay endpoint: reads, results and the attached-file list travel over an authenticated WebSocket, request ids are assigned by the host so answers reach only the process that asked, and attachedFiles and the selection read the same in every process. When the host exits, a remaining process takes the port over at once (the OS gives it to exactly one) and the plugin re-attaches on its own two-second retry. A read in flight at that moment is sent again once the plugin is back - reads do not change the document - so a collection under way finishes (measured: 2.0 s after its holder was killed) instead of failing; it fails only if the plugin is not back within 10 s, and a read whose plugin window closed fails at once instead of after 90 s. The plugin now names its window with a sessionId, so a plugin that cannot report its file key (Dev Mode) keeps its routing key across reconnects and handovers, and it understands devup-cancel: a read nobody waits for any more - the process that asked went away, or it timed out - is dropped from the plugin's queue, or its answer withheld if it was already running. Older plugin builds ignore both and keep working. Relaying is limited to the same user's devup-mcp: both sides prove knowledge of a secret with HMAC over fresh nonces, and the secret never crosses the wire. It is kept in %USERPROFILE%\AppData\Local\devup-mcp\bridge-relay.key on Windows and in /tmp/devup-mcp-/bridge-relay.key on macOS and Linux - chosen by user id rather than HOME, which MCP clients set differently, so two sessions of one user always find each other; that directory must belong to this user with mode 0700, is closed and its secret replaced if it was open, and is refused if it belongs to someone else or is a link. Browser pages cannot pose as either side: /relay refuses any Origin, and /plugin admits only the Figma plugin's null origin and figma.com. Nothing listens beyond 127.0.0.1, and the relay handshake carries a protocol version so an incompatible peer is refused rather than trusted. devup_figma_auth status/doctor report paths.bridge.role (host, relay, connecting, unavailable), the holder's pid/version/buildId, handoverFrom while the port changes hands, and for an unusable port an issue - legacy-host, foreign-program, incompatible-protocol, authentication-failed - with the step that fixes it, within seconds rather than waiting. A holder that does not say who it is - a devup-mcp from before sharing, or another program - is named by pid, process name and executable path as the operating system reports them, added after the first answer so status never waits on the lookup. available is true only when a read can be sent now, and a relay with the plugin reachable never suggests logging in. Reads the bridge serves are no longer held to the metered pace (DEVUP_FIGMA_CALLS_PER_MINUTE, eight a minute by default), which made a second export on the same server wait most of a minute for an allowance it was not spending. --self-check and a server built in-process for tests no longer open the bridge. DEVUP_FIGMA_BRIDGE_PORT keeps its meaning and a single process behaves and answers as before.