Termix/packages/plugin-sdk/FINISH-LIST.md

Finish list

Running list of things intentionally left unfinished by a Phase B/C step, so D0 (or an earlier owner named below) can pick them up. Remove a line once it's done.

• B3 (tailscale): ManagerCardShell/ManagerSearch-equivalent presentation is duplicated as TailscaleManagerShell/TailscaleManagerSearch in plugins/tailscale/src/frontend/TailscaleManagerShell.tsx rather than shared with host-metrics's originals. Promote a shared version into @termix/plugin-sdk/ui once a second manager-card plugin needs one, per the contract's "add to the SDK when a second plugin needs it" rule. Owner: D1.
• B3 (tailscale): plugins/tailscale/src/backend/host-metrics-manager.ts and routes.ts still resolve hosts and access through core's PermissionManager/resolveHostById/DataCrypto by relative import instead of ctx.hosts, which B4 built. Same debt every other host-metrics manager already carries; not new, but tailscale now carries it too. Owner: host-metrics's own Phase B step (it and every manager plugin convert together).
• B4 (fleets/host-metrics): src/backend/hosts/metrics-shared/ (platform detection, package commands, exec-elevated) is still core's own copy, used by host-metrics, which has not converted yet. @termix/plugin-sdk/host-commands is the SDK copy fleets now uses; core's copy was left in place rather than turned into a re-export, since host-metrics's own conversion step is where its imports should move wholesale. Owner: host-metrics's Phase B step.
• B5 (proxmox): runAdaptivePolling and cn are duplicated in plugins/proxmox/src/frontend/stats/ rather than shared with core's src/ui/lib/ originals. useConnectionRetry (the third duplicate B5 left here) is resolved: B6 promoted it into @termix/plugin-sdk/frontend once file-manager became its fourth caller (after proxmox, docker, host-metrics, remote-desktop) and switched proxmox's own copy over too. host-metrics's own conversion needs runAdaptivePolling for its stats tab, so promote it into @termix/plugin-sdk/frontend (and cn into @termix/plugin-sdk/ui) the next time either is touched. Owner: D1, or host-metrics's Phase B step if it lands first.
• B5 (proxmox): runDueProxmoxAutoSyncs in plugins/proxmox/src/backend/routes.ts still reaches createCurrentPluginSettingsRepository/createCurrentHostRepository by relative import instead of ctx, because it needs to scan every host's Proxmox settings across every user before it knows which actor to run each sync as, and neither ctx.settings nor ctx.hosts expose a cross-user bulk read today. A ctx.settings.listHostsWithKey or similar SDK addition would close this, if a second plugin's background scan ever needs the same shape. Owner: D1.
• B6 (file-manager): plugins/file-manager/src/frontend/components/PdfPreview.tsx runs pdfjs without a worker (main-thread parsing) because termix-plugin build's esbuild step has no static-asset-copy pipeline the way core's Vite build resolves a ?url import to a hashed /assets/ file. Fine for the small files this preview usually opens; restoring a real worker needs the CLI (packages/plugin-sdk/cli/commands/build.mjs) to gain a way to emit an extra file into dist/ and have the frontend reference it by its served /plugin-assets/<id>/ path. Owner: D1, or whichever step first needs a worker or other static asset from a plugin bundle.
• B6 (file-manager): transfer-tuning.ts's adaptive-tuning profile still persists to a JSON file under DATA_DIR rather than ctx.kv, and HostFilesTab.tsx's t() calls plus the manifest's contributes.settings.host labelKeys deliberately point at two different key paths (hosts.* and settings.host.*) for the same three fields, both carrying the same English text - a minor duplication from keeping the host editor's exact existing section verbatim (registerHostEditorSection) instead of switching it to the schema-driven settings form. Neither blocks anything; flagging for whoever next touches this plugin's settings UI.
• B6 (file-manager): TabContext.tsx's computeUniqueTitle compares tabType === "file_manager" (an activity-log type string, not a tab type - the real tab type has always been "files"), so that branch has never matched and silently falls through to the terminal title. Pre-existing, unrelated to the conversion; noted rather than fixed per the lean-mode rules. Owner: whoever next touches tab title logic.
• B6 (file-manager): enable_file_manager, default_path and scp_legacy are still live ssh_data columns; only the copy-into-plugin- settings migration shipped (file-manager-settings-migration.ts). Every core read site the earlier exploration found (host.ts, host-normalizers.ts, host-bulk-routes.ts, credentials.ts, host-internal-routes.ts, database.ts's encrypt/decrypt round trip, plugins/host-view.ts, ctx-hosts.ts, plus the frontend's HostEditorData.ts/HostManagerData.ts/SidebarTree.tsx/quick-connect mapping) still reads the column directly rather than ctx.settings.getHost. Switching every one of those and then dropping the column in lockstep (schema.ts, db/index.ts, a drizzle migration per dialect, schema:generate) is real, separate work this step didn't attempt, since none of those reads block the plugin conversion itself. Owner: a dedicated follow-up step, or D0.
• B7 (tunnels): enable_tunnel and tunnel_connections are still live ssh_data columns; only the copy-into-plugin-settings migration shipped (tunnels-settings-migration.ts), and the plugin reads its host settings now. Core still carries the columns through the host routes, the encrypt/decrypt round trip, SidebarTree.tsx's host duplicate payload, the quick-connect mapping and the Host/SSHHost types, none of which the plugin reads any more. Dropping them in lockstep (schema.ts, db/index.ts, a drizzle migration per dialect, schema:generate) is the same follow-up the B6 file-manager line above describes. Owner: a dedicated follow-up step, or D0.
• B7 (tunnels): host export/import, host duplicate, the Hosts panel feature filter and the bulk enable/disable menu all work off ssh_data columns, so none of them can see a plugin's host settings. For tunnels the "Tunnel" filter and the bulk enable/disable entries were removed, and the export's "Tunnels" group became "Proxy" (SOCKS5 fields only) since tunnelConnections there is now stale. Bringing these back needs a way for core to read and write host-scope plugin settings generically (keyed off contributes.settings.host or hostCapability) rather than per column. Owner: D1.
• B7 (tunnels): the tunnel tab no longer writes a recent-activity entry: logActivity is a core @/main-axios call and the plugin imports nothing from @/. Old "tunnel" entries still reopen the tab through the plugin's activityTypes. An app.logActivity (or equivalent bridge member) would restore it for this plugin and let docker, file-manager and host-metrics drop their own @/main-axios import for it too. Owner: D1.
• B7 (tunnels): on the desktop app, tunnel statuses from a connected remote server are no longer merged into the tab: the old code polled the remote tunnel service through getRemoteTunnelApi(), and the SDK has no remote-origin plugin API client. subscribeTunnelStatuses already takes a fetchRemote and merges with local statuses winning, so it only needs a client for /plugin-api/tunnels/status on the remote server. Owner: D1.
• B8 (web-endpoint): enable_web_ui and web_ui_config are still live ssh_data columns; only the copy-into-plugin-settings migration shipped (web-endpoint-settings-migration.ts). Unlike B6/B7, this step DID convert every core read/write of those two fields (host.ts's create/update and export routes, host-normalizers.ts, host-bulk-routes.ts, database.ts's encrypt/decrypt round trip is the one exception - it copies whatever is already in the column for the raw DB export/backup tool, which needs no change since nothing reads that copy through pluginSettings). Dropping the columns in lockstep (schema.ts, db/index.ts, a drizzle migration per dialect, schema:generate) is the only remaining piece. Owner: a dedicated follow-up step, or D0.
• B8 (web-endpoint): added the first generic cross-plugin hook for core routes that touch host-scope plugin settings without importing a plugin: ctx.registry.provide("<id>.hostImportNormalizer", fn) plus applyPluginHostImportSettings in host-plugin-settings.ts, called from host-bulk-routes.ts's Termix-JSON import path. Only import validation is covered; B7's TODO above about the Hosts panel feature filter and the bulk enable/disable menu (hostCapability-driven, not import-driven) is unrelated and still open. Owner: D1 for extending the same pattern there.
• B8 (web-endpoint): noticed while sanity-checking with npm run lint (not required by this step): eslint.config.mjs's globalIgnores(["dist", ...]) only matches a top-level dist/ folder, not nested packages/*/dist or plugins/*/dist, so npm run lint fails on bundled output repo-wide with "Definition for rule X was not found" errors. Pre-existing, not introduced by this or any single plugin step. Owner: whoever next needs a clean npm run lint, or D0.
• B8 (web-endpoint): the isolated-window Electron IPC bridge (src/backend/utils/electron-ipc-bridge.ts, ctx.desktop.openIsolatedWindow) is a single request/response channel keyed by a random id with one registered backend-request handler (open-isolated-window) in electron/main.cjs. Fine for today's one caller; if a second plugin needs to ask Electron's main process for something, extend BACKEND_REQUEST_HANDLERS there rather than building a parallel channel. No owner needed unless a second caller appears.
• B9 (ssh-terminal): session sharing has no provider yet. The terminal consumes sessions.sharing v1 (member joins through authorizeJoin and recordJoin, collab room events through subscribeRoom/unsubscribeRoom) and reads guest link resolution from ctx.registry as sessions.sharing.guests (resolve, recordJoin), all typed in plugins/ssh-terminal/src/backend/services.ts. Until something provides them, share-link and room guests are refused and in-app joins fail. Core's session-sharing, collab and open-tabs code reach the terminal through sessions.live already. Owner: B12, which provides both from the session-sharing plugin (the lookups are the old code in hosts/session-sharing and hosts/collab: share repo, room repo, guest rate limit, canJoinRoomStageShare, session_sharing_globally_enabled, host allowSessionSharing, getAuditUsername for labels, collabRoomHub). B12 also moves eventsWsPath in collab/routes.ts and the share dialog the shell opens from a tab's getShareTarget().
• B9 (ssh-terminal), for D2: the terminal socket is a public route with optionalAuth, because share-link and room guests authenticate inside the handler with their token. Guest auth itself is unchanged; review it with the rest of the public routes.
• B9 (ssh-terminal): recording has no provider yet. The terminal calls the optional recordings.writer v1 open(meta) and gets a sink with append(chunk) (one call per 300 ms batch, the first starting with the asciicast header), persist(summary) and discard(). Without it nothing is recorded and no session_recordings row is written. Owner: B13, which writes the file under DATA_DIR/session_logs/<user>/<session>.cast (mkdir and writeFile on the first append, appendFile after, never per chunk, see issue #1049) and creates or updates the row as the old session manager did.
• B9 (ssh-terminal): enable_terminal, enable_terminal_toolbar and enable_command_history are still live ssh_data columns. The copy into ssh-terminal host settings shipped (ssh-terminal-settings-migration.ts) and the terminal reads its settings, but core host routes, types, the export/import sample and HostEditorData still carry the columns. enable_terminal_toolbar also drives the RDP/VNC/Telnet toolbar (remote-desktop/GuacamoleApp.tsx), whose host editor switch stays in the General tab, so remote-desktop needs its own host setting and copy first. Then drop all three in lockstep. Owner: remote-desktop's step for its copy, then D0.
• B9 (ssh-terminal): the legacy settings rows for the terminal (terminal_session_timeout_minutes, terminal_session_persistence_enabled, command_history_enabled, touch_input_settings, terminal_image_*) are left in place for a release after the move; nothing reads them. Delete them in 3.0.0. sessionPersistence is carried over but, as before, nothing acts on it. Owner: D0 to decide.
• B9 (ssh-terminal): the image storage paths used to be rejected at save when not absolute; the schema-driven settings form accepts any string and the resolver ignores a bad one with a warning. A custom field or a validate hook on plugin settings would restore the save-time error. Owner: D1.
• B9 (ssh-terminal): @termix/plugin-sdk/ui now re-exports a handful of core APIs the terminal needs (logActivity, getHostPassword, patchOpenTab, getUserPreferences, parseCustomKeybindings, setHostAutoTmux, getCookie) and the connection helpers. They belong on the typed host bridge, which is also where B7's app.logActivity line above lands. Owner: D1.
• B9 (ssh-terminal): OPKSSHDialog is exported from @termix/plugin-sdk/ui so the terminal can show the opkssh sign-in. It leaves the ui entry when opkssh becomes a plugin that draws its own UI in terminal.overlay. Owner: Phase C (opkssh).
• B9 (host-metrics): the terminal toolbar's CPU/memory/disk bars (TerminalMetricsStatus) poll the local backend only; on the desktop app a host that lives on a connected remote server shows no bars. Same fix as the B7 remote-origin line above. Owner: D1.
• B9: the Hosts panel's "Terminal" feature filter was removed along with the column reads, the same as B7's tunnel filter. Owner: D1, with the generic host-settings filter.
• B9: the startup purge of expired open tabs in db/index.ts read terminal_session_timeout_minutes from core settings; it was removed and expired tabs are dropped when the tab list is read, against the terminal's own timeout (GET /open-tabs/session-timeout, 30 while the terminal is off). No owner unless the table growth matters.
• Pre-existing (B8), found in B9: node scripts/check-shell-plugin-ids.cjs fails on src/ui/lib/host-to-ssh-host.ts spelling web-endpoint (the pluginSettings lookup B8 added). Not allowlisted and not introduced here. Owner: D0 (read it through a registry or allowlist it with a reason).
• B10 (tmux-monitor): enable_tmux_monitor is still a live ssh_data column; only the copy-into-plugin-settings migration shipped (tmux-monitor-settings-migration.ts), the same as B6/B7's own columns. Every core read site (host.ts, host-normalizers.ts, host-bulk-routes.ts, database.ts's encrypt/decrypt round trip) still reads the column directly. Dropping it in lockstep (schema.ts, db/index.ts, a drizzle migration per dialect, schema:generate) is the same follow-up the B6/B7/B8 lines above describe. Owner: a dedicated follow-up step, or D0.
• B10 (tmux-monitor): terminalToolbar.openTmuxMonitor and terminalToolbar.tmuxDetach are dead locale keys (nothing calls t("terminalToolbar.openTmuxMonitor") or t("terminalToolbar.tmuxDetach") anywhere in the tree; the terminal's own live detach button uses terminalToolbar.detachTmux/detachTmuxDescription instead). Pre-existing, not introduced by this step; sibling dead keys (copyTerminalUrlAction/copyDockerUrlAction/copyHostMetricsUrlAction, terminalUrlCopied/dockerUrlCopied/hostMetricsUrlCopied) are the same vintage, from before the generic hosts.copiedToClipboard/ copyViewUrlAction replaced them. Owner: whoever next cleans up src/ui/locales/en.json, or D0.
• B10 (tmux-monitor): no plugin contributes an "Open Tmux Monitor" (or "Open Docker" / "Open Tunnel" / "Open Host Metrics") quick link into terminal.toolbar today; that whole quick-link row was dropped when the toolbar was rebuilt as a generic action slot (ai is the only real terminal.toolbar contributor, for its assistant button) and never replaced per-feature. Adding tmux-monitor's own link is straightforward (app.registerSlotContribution("terminal.toolbar", ...) plus app.registerAction opening the singleton tab) but is a shared gap across four plugins, not specific to this step. Owner: D1, or whoever revisits the toolbar's quick-link row.
• B11 (serial): plugins/serial/src/frontend/Serial.tsx uses a small hardcoded light/dark xterm palette and a generic monospace font stack instead of the app's real terminal theme system (resolveTermixThemeColors, DEFAULT_TERMINAL_CONFIG, TERMINAL_FONTS, font loading), which is still core-only (src/ui/features/terminal/, src/ui/lib/terminal-themes.ts) and not yet exposed through the SDK. The serial console therefore does not match a user's chosen terminal theme or font. Promoting that system into @termix/plugin-sdk/ui is really ssh-terminal's own Phase B step's call to make (it is the plugin that currently owns the terminal component itself, per the "Known specifics" note above), so this line just points at the gap rather than building a premature shared surface for one caller. Owner: ssh-terminal's own Phase B step, or D1.
• B11 (serial): shipping a plugin's own native dependency (serialport) works for this repo's three bundled deployments only because they all install the whole npm workspace at once and copy/rebuild one shared node_modules - see "Native dependencies" in ARCHITECTURE.md for the full reasoning. A community plugin installed later from a tarball has no such shared node_modules to land in, so it cannot ship a native dependency the same way. No fix attempted here; the honest workarounds are listed in that section. Owner: whoever designs the 3.0.0 install flow (prebuild-per-platform packaging, or a documented "avoid native code" rule for community plugins).

Manual checks after 2.9.0

• SSH terminal: password auth, key auth (and an encrypted key's passphrase prompt), TOTP keyboard-interactive, a jump host, Warpgate, split view, snippets sent to a terminal, reconnect after a network drop and after a page reload (session reattach), and the local terminal in the desktop app.
• Serial: the Electron backend path against a real device path/COM port, and the Web Serial browser picker in Chrome or Edge.