>_Executive summary
Where COMPONENTS.md says what an app pulls in, this says what an app turns on. Every full Tauri app mounts the same zgui-core shell, so the power-user surfaces — GUI scripting bus, tmux/powerline status bar, tmux tiling WM, editor vim, stryke hooks editor — are near-universal by construction (the identical cyberpunk HUD across apps is intentional). Several ship in zgui-core but must be init()'d per app, so presence is verified at the call site. The signal is at the outliers: zterminal ships native everything (no webview shell) and the JUCE plugins have no webview at all.
~What each surface is
| Surface | Where it lives | What it is |
|---|---|---|
| GUI scripting (bus) | zgui-bridge (Rust socket) + zgui-core/webui/automation*.js | Per-app Unix socket so a stryke script drives the app by name — App::open("<app>")->call(...), and App::here() from a hook running inside it. Verbs cataloged in GUI_SCRIPT_ACTIONS.md. |
| tmux status bar | zgui-core/webui/powerline.js (ZGui.powerline) | Powerline bar pinned to the bottom: C-b prefix light · scheme · tmux windows · VIM segment · CPU/MEM/SWAP/DISK/IO/NET/LOAD/UP/TEMP/BATT/LAN/WAN/host/clock. Ported from zwire's zstatus.js. |
| tmux tiling WM | zgui-core/webui/tmux.js (ZGui.tmux) | Real in-app tiling overlay: SESSION → WINDOWS (tabs) → PANES, split both ways, nested, copy-mode, synchronize-panes, command-prompt. Ported from zwire's ztmux.js. |
| vim (editor) | zpwr-hooks-editor → monaco-vim | Vim keybindings + :cmd line inside the Monaco hooks editor — present wherever the hooks editor is. |
| vim (app-level) | app-owned | Vim navigation over the whole app UI (hjkl / marks / / search / :cmd), not just inside an editor. |
| hooks editor | zpwr-hooks-editor | Monaco stryke-hooks editor embed. |
#Track A — Tauri / webview apps
✓ wired · · not wired · native app implements its own, not the zgui-core one · "Bus verbs" = the app's live automation-bus surface (verbs() over the socket: appShell + engine + dynamically-registered), read from the running app by bin/gen-gui-actions-live and cataloged in GUI_SCRIPT_ACTIONS.md.
| App | GUI scripting | Bus verbs | tmux bar | tmux WM | vim (editor) | vim (app) | hooks editor |
|---|---|---|---|---|---|---|---|
| zpdf | ✓ | 649 | ✓ | ✓ | ✓ | · | ✓ |
| zcite | ✓ | 206 | ✓ | ✓ | ✓ | · | ✓ |
| zemail | ✓ | 208 | ✓ | ✓ | ✓ | · | ✓ |
| zftp | ✓ | 160 | ✓ | ✓ | ✓ | · | ✓ |
| zreq | ✓ | 151 | ✓ | ✓ | ✓ | · | ✓ |
| ztunnel | ✓ | 125 | ✓ | ✓ | ✓ | · | ✓ |
| zoffice | ✓ | 199 | ✓ | ✓ | ✓ | ✓ | ✓ |
| zthrottle | ✓ | 91 | ✓ | ✓ | ✓ | · | ✓ |
| zgo | ✓ | 140 | ✓ | ✓ | ✓ | · | ✓ |
| traderview | ✓ | 1732 | ✓ | ✓ | ✓ | · | ✓ |
| zphoto | ✓ | 101 | ✓ | ✓ | ✓ | · | ✓ |
| zstation | ✓ | 37 | ✓ | ✓ | ✓ | · | ✓ |
| zcontainer | ✓ | 25 | ✓ | ✓ | ✓ | · | ✓ |
| Audio-Haxor | ✓ | 239 | ✓ | ✓ | ✓ | · | ✓ |
| ztranslator | ✓ | 54 | ✓ | ✓ | ✓ | · | ✓ |
| zwire | native2 | 161 | ✓ | ✓ | ✓ | ✓ | ✓ |
| zterminal | · | — | native3 | native3 | · | · | · |
On the counts — every Bus-verbs number is the app's live surface, read from the running app over its automation-bus socket by bin/gen-gui-actions-live (a stryke script that opens each app, queries verbs() via a native Unix-domain socket, and closes it). It captures the whole runtime surface — appShell verbs, engine/opts.commands, and verbs registered dynamically at load — which a static source grep cannot see. A static verb source is often larger than the live bus surface (an engine may expose 218 internal ops but wire only 25 onto the bus), so these are the authoritative callable counts.
2 zwire scripts through its own native bus (zwire-host/src/zbus.rs, 161 verbs — the Chromium-superset browser control surface: tabs/windows/tab-groups/downloads/reading-list/power), not the zgui-bridge socket. Its powerline bar, tmux WM, and app-level vim originate here — zgui-core's powerline.js / tmux.js are the generalized ports of zwire's zstatus.js / ztmux.js.
3 zterminal is the GPU terminal itself: it ships a native status bar and native tmux (the ztmux-core wire-protocol client), not the zgui-core webview components. It doesn't mount the appShell, so it has no automation-bus socket, no hooks editor, and no editor vim (vim runs inside it).
#Track B — JUCE plugins
zpwr-daw engine · zpwr-synth · zpwr-fx · zpwr-midi-fx. No window.ZGui, no Tauri invoke. The automation-bus, powerline bar, and tmux WM are not wired for the JUCE surface — the bus substrate for Track B (C++/C-ABI, per-plugin-instance socket addressing) is still unbuilt (see GUI_AUTOMATION_BUS_CHECKLIST.md §0B). zpwr-daw's Tauri shell carries monaco-vim + the hooks editor through its embedded ztranslator-core webview; the JUCE ClipEngine half does not.
*Notes
- The webview surfaces are shared, so the answer is "nearly all of them." The differentiation is at the outliers:
zterminal(native everything, no webview shell) and the JUCE plugins (no webview at all). Every full Tauri app mounts the samezgui-coreshell and gets the same bar / tmux WM / hooks / editor-vim by construction — this uniformity is intentional. - App-level vim (whole-UI vim navigation, not just the Monaco editor) is only in zoffice (
zoVimModeediting mode) and zwire (browser-wide vim keys). Everywhere else "vim" means themonaco-vimbinding inside the hooks editor. - GUI scripting is live, not planned.
GUI_SCRIPT_ACTIONS.mdis regenerated from each app's verb source (bin/gen-gui-actions.sh) and currently lists 4308 live bus verbs across 17 apps + 15 shared appShell verbs. The remaining socket-wired apps expose their Tauri commands via webview-forward until their typed verbs are promoted into the catalog.