// MENKETECHNOLOGIES — INVENTION LEDGER

One person built the whole execution engine — a bytecode VM plus a 3-tier (linear/block/tracing) Cranelift JIT emitting native machine code at runtime, and an AOT object compiler — and eight independent language frontends (strykelang/Perl 5, zshrs/zsh, awkrs/AWK, vimlrs/VimL, elisprs/Emacs Lisp, rubylang/Ruby, pythonrs/Python, and the original pipeline-UI language arb) each targeting the same fusevm bytecode. The novelty is the combination: solo author + from-scratch VM with a genuine machine-code JIT + 8+ real frontends. Basis: fusevm/src/jit.rs builds a cranelift_jit::JITModule, transmutes finalized functions to native fn pointers, with an mmap+PROT_EXEC disk cache; fusevm/src/aot.rs emits a relocatable .o via cranelift_object; eight crates already depend on fusevm and emit fusevm::Chunk/Op (arb's compute core — its calc / expression layer — lowers to a fusevm::Chunk via arb/src/expr.rs and runs on the VM, while its widget / layout construction stays a native ratatui interpreter). fusevm/src/op.rs (~224 ops), host.rs/awk_host.rs host-trait injection seam. Caveat: "None found", not proven — the deep search (see analysis) found no project meeting all three criteria but cannot cover private/defunct work; the nearest near-miss (Deegen) is contestable. JIT is opt-in behind Cargo features; interpreter is the default fallback.

Whole-program AOT lowers each bytecode op to a native basic block that calls back into the same VM::exec_op the interpreter uses (via an extern "C" shim), so AOT and interpreter semantics can never diverge. Basis: fusevm/src/aot.rs fusevm_aot_exec_op → VM::aot_exec_op → VM::exec_op; compile_object emits a .o exporting fusevm_aot_entry + serialized chunk; staticlib crate-type. Caveat: for unspecialized ops this is threaded-code AOT (native dispatch + shared per-op call) more than maximal native lowering; the win is removing the dispatch loop and forbidding a semantic fork.

A from-scratch tracing JIT inlines calls (incl. bounded self-recursion), traces branches across caller and inlined-callee frames, stitches side traces at hot side-exits, and on deopt reconstructs full interpreter state (synthetic frames + live stack) to resume mid-callee. Basis: fusevm/src/jit.rs (DeoptInfo/DeoptFrame; the bounds are JitConfig fields — max_inline_recursion and max_trace_chain, both defaulting to 4, jit.rs:344-363); fusevm/src/vm.rs materialize_deopt_frames(). Caveat: speculative tracing JITs with deopt/side-traces are well-trodden (LuaJIT, PyPy, TraceMonkey) — novelty is implementation, not concept; hard bounds make it narrower than production tracers. Not a categorical first.

An opt-in on-disk cache persists compiled native code for linear, block, and tracing tiers across process restarts, keyed by chunk op-hash (tracing also by anchor IP + content hash), with a conservative relocation loader that falls back to in-memory JIT on any unknown relocation — so it only removes codegen time, never changing results or tier selection. Basis: jit-disk-cache feature in fusevm/Cargo.toml; fusevm/src/jit.rs SCHEMA_VERSION, FNV reloc IDs, Apple-Silicon W^X handling, atomic temp+rename; fusevm/benches/jit_disk_cache.rs. Caveat: persistent JIT caches exist; the notable combination is covering a tracing tier in a hand-written VM. W^X/reloc correctness not independently tested here.

awkrs persists compiled AWK bytecode to disk and reloads it on later runs, and separately persists fusevm-emitted machine code across processes — two-tier persistence the README's survey of BWK/gawk/mawk/goawk/frawk/zawk finds in none. Basis: awkrs/src/script_cache.rs (rkyv shard ~/.awkrs/scripts.rkyv, flock-atomic); machine-code tier from fusevm jit-disk-cache. Caveat: "first" is a self-conducted survey; the machine-code tier engages only for JIT-eligible numeric chunks.

rubylang is the sixth fusevm frontend: it lexes and parses Ruby to an AST, lowers it to fusevm bytecode on a RubyHost object heap, and runs it on the shared three-tier Cranelift JIT + native-AOT engine — with no bespoke VM or JIT of its own. Arithmetic/comparison operators lower to native VM ops so the JIT can trace hot loops; Ruby-specific behavior (method dispatch, blocks / yield / closures, object construction) is served by a thread-local runtime host. Implemented: classes with initialize/attr_*/single inheritance/super, modules + include mixins, class methods (def self.m), exceptions (begin/rescue/ensure, method-body and modifier rescue, typed exception classes), splat params, &:sym block-pass, parallel assignment, default args, the standalone ruby binary + REPL, the rkyv bytecode cache, an AOP method-intercept registry, and an LSP server. Basis: rubylang/src/{lexer,parser,compiler,host,cache,intercepts,lsp,dap,aot}.rs (~6,989 L); Cargo.toml fusevm = "0.14.10" with jit/jit-disk-cache/aot; a differential parity harness (cargo run --bin parity) diffs a 35-snippet corpus live against the reference ruby, and tests/parity.rs replays the frozen outputs in CI with no ruby installed. Caveat: mruby already compiles Ruby to bytecode (in C, since 2012) and Artichoke is a Ruby-in-Rust interpreter, while TruffleRuby JIT-compiles Ruby but on the JVM/GraalVM — so the defensible "first" is the narrower combination: Ruby lowered onto a shared multi-frontend fusevm bytecode + Cranelift JIT + native AOT, authored in Rust, not "first compiled Ruby" outright. Early: DAP is partial (handshake + run-to-completion, stepping pending); extend/prepend, keyword params, regex, and bignum are planned (BUGS.md). "First" rests on a non-exhaustive prior-art sweep. MIT.

pythonrs is the eighth fusevm frontend: it lexes and parses Python to an AST, lowers it to fusevm bytecode on a PyHost object heap, and runs it on the shared three-tier Cranelift JIT + native-AOT engine — with no bespoke VM or JIT of its own. Arithmetic/comparison operators lower to native VM ops so the JIT can trace hot loops; Python-specific behavior (attribute access, container operations, object construction) is served by a thread-local runtime host. Implemented: the standalone python binary + REPL, the core builtin surface (print/len/range/int/str/list/dict/sorted/enumerate/zip/map/filter and more), the transparent rkyv bytecode cache on every run, AOT compilation to a standalone native executable, an AOP method-intercept registry, a DAP debug server, and an LSP server. Basis: pythonrs/src/{lexer,parser,compiler,host,cache,intercepts,lsp,dap,aot}.rs (~5,999 L); Cargo.toml fusevm = "0.14.10" with jit/jit-disk-cache/aot; a differential parity harness (cargo run --bin parity, src/bin/parity.rs) diffs the example corpus live against the reference python3. Caveat: CPython already compiles Python to bytecode (in C, on its own VM) and PyPy JIT-compiles Python on RPython's own tracing JIT, while RustPython is a Python-in-Rust interpreter — so the defensible "first" is the narrower combination: Python lowered onto a shared multi-frontend fusevm bytecode + Cranelift JIT + native AOT, authored in Rust, not "first compiled Python" outright. Early: generators / yield are rejected at call time, async/await is parsed but await is a no-op (no event loop), and **kwargs / keyword-only params are planned (BUGS.md). "First" rests on a non-exhaustive prior-art sweep. MIT.

arb is an original language (not a port) that drops into a Unix pipe and spawns a dynamic ratatui TUI — and, later, a zgui web page — from a declarative, Tcl/Tk-flavored spec. It is now well past the M0/M1 sketch: a ~100-verb query engine (103 QueryOp variants, a jq/xpath/css/yq superset over six input formats — line / JSON / CSV / TSV / YAML / TOML / HTML), 14 widget kinds (text/tail/list/gauge/bars/histo/spark/chart/table/tabs/block/frame/input/select), an interactive megafilter/map (the input widget + apply verb splice a live-edited value into a source pipeline, re-evaluated every frame — a before/after transform editor as a spec), and a non-blocking pipe architecture: the TUI renders to /dev/tty and reads keys from /dev/tty (like vipe), so stdout stays a clean data channel and find / | arb | consumer streams through untouched while the UI runs. The compute core is wired to fusevm — expressions and the calc op lower to a fusevm::Chunk and run on the VM + three-tier Cranelift JIT (arb/src/expr.rs; Cargo.toml depends on fusevm = "0.14.10" with jit). The world-first framing is the synthesis — no prior tool is a pipe-native, dual-target (terminal + web), component-generating UI language with a shareable dashboard registry (each leg has prior art: Tcl'88 / Tk'88 / Expect'90, dasel, ratatui, Streamlit / Textual-serve, filt). Basis: arb/README.md + arb/SPEC.md; arb/src/*.rs (~5,611 L, 138 tests); arb/src/query.rs (the 103-op engine), arb/src/expr.rs (fusevm lowering), arb/src/tui.rs (/dev/tty render + raw key read). Caveat: the web target, Akka-style actors, Expect-style reactions, and the package-manager registry are still unbuilt milestones; "world-first" is author-asserted on the synthesis per SPEC's own per-leg prior-art table. MIT.

fzf (2013) is not a competitor arb happens to beat — it is a strict subset of one arb widget. arb --fzf and a select widget are literally the same code path (fzf_mode = cli.fzf || any select widget, arb/src/main.rs), and --fzf synthesizes a one-widget select spec (default_spec_src), so sudo find / | fzf ≡ sudo find / | arb -e 'select .s'. fzf's entire feature surface — fuzzy smart-case match, multi-select marks, cursor nav, prompt/header, preview pane — is one of arb's 14 widget kinds; the other thirteen are TUIs fzf cannot express. On fzf's own axis arb is a superset, not a clone: it carries fzf's real performance tricks (query-extension incremental match — typing narrows only the current hit set since fuzzy match is monotonic; rayon parallel rescan + parallel sort; windowed rendering of visible rows only) and adds what fzf structurally cannot do — (1) non-blocking: renders/reads keys on /dev/tty and tees the filtered stream downstream live, where fzf owns stdout and blocks the pipe until Enter; (2) fd-owning stderr isolation: the orchestrator (PROD | _ | CONS) makes arb spawn every stage and route the producer's stderr to a pane, so sudo find / permission errors never scribble over the list — fzf can't intercept an upstream it didn't spawn; (3) a ~100-verb query engine that sees fields / JSON paths / CSV columns, where fzf sees opaque lines. The world-first framing is not "faster fzf" (dead by the no-dup rule — a faster fzf fails the "world's first" leg) but "arbitrary interactive TUI from a pipeline DSL, non-blocking and fd-owning, of which fuzzy-select is one preset." Basis: arb/src/main.rs (fzf_mode, default_spec_src), arb/src/spec.rs (WidgetKind::Select), arb/src/tui.rs (/dev/tty render + raw key read, query-extension incremental match, par_iter/par_sort_by, render_err_pane stderr pane), arb/src/query.rs (103-op engine). Caveat: the select widget currently drives off the raw stream — a select source pipeline (reshaping candidates before display) and mixing select with dashboard widgets in one spec are the next increments, not yet wired; the fuzzy-parity + non-blocking + stderr claims above are all in-tree and build-green. MIT.

Tab/prompt/alias lookups read daemon-built bytecode via direct mmap (~150–200 ns, no IPC per call) while only configuration mutation crosses a JSON-over-Unix-socket control plane. Basis: src/extensions/canonical_apply.rs mmaps ~/.zshrs/images/*-recorder.rkyv into the executor's HashMaps at cold-start (the doc rejects the earlier per-startup-IPC version as 5–10 ms too slow); DESIGN_GOALS.md §0x04a hard-rule #2. Caveat: an architectural design point; overlaps the daemon claim.

The daemon doubles as a general service — persistent KV, job submission, cross-process locks, fsnotify triggers, pub/sub, build-artifact cache, cron-equivalent scheduling — usable from bash/fish via an HTTP client with scoped auth tokens, collapsing cron/anacron/launchd/flock/sccache into one daemon. Basis: docs/DAEMON_AS_SERVICE.md; daemon/http.rs, bins/zd.rs HTTP client, daemon/auth.rs (scoped vs flat tokens, scope_denied 403), daemon/schedule.rs (6-field cron, sqlite tick loop). Caveat: some endpoints are v1/partial; the decoupling thesis is partly forward-looking.

Cross-shell publish/subscribe as native daemon primitives — scope/topic subscriptions (shell:<id>, tag:<name>, user:<name>, *) over command/chpwd/prompt/exit/signal topics, brokered without filesystem-IPC polling. Basis: daemon/pubsub.rs; builtins zsend/zsubscribe; RFC contrasts zconvey (filesystem-IPC + per-prompt polling). Caveat: the cross-host federation leg is largely unbuilt (see #34).

Native jobs supervised by the daemon survive shell exit at process granularity (not terminal granularity), with captured stdout/stderr and queryable status — replacing nohup/disown/setsid/pueue/screen-as-runner. Basis: daemon/jobs.rs (38 KB), daemon/zjob_builtin.rs (output to ~/.zshrs/jobs/{id}.{out,err}). Caveat: author framing as "tmux at process granularity"; restart-policy maturity unverified.

Snapshots a running shell's entire mutable overlay (aliases, global/suffix aliases, options, params/arrays/assoc, env, path/fpath/manpath) into a daemon canonical store so other shells pull it — cross-shell state sync as a builtin. Basis: src/extensions/overlay_snapshot.rs enumerate_all_overlays + daemon/zsync.rs (push/pull/diff, canonical_changed event) + daemon/canonical.rs. Caveat: v1 stores canonical as JSON in catalog.db.

The IDE integration reads plugin-manager state and exposes each plugin as a navigable, indexable, find-usages-able IDE library root, grouped by inferred manager. Basis: zshrs --dump-plugins (reads plugin_cache SQLite, plugin_cache.rs 68 KB); JetBrains ZshrsLibraryRootProvider.kt/ZshrsPluginRegistry.kt implementing AdditionalLibraryRootsProvider. Caveat: scoped to the bundled JetBrains plugin.

zsh completion functions pre-compile to fusevm bytecode stored in mmap'd rkyv shards (consumed zero-copy on Tab), replacing zsh's re-interpret-shell-script-per-Tab model where ~11,656 lines of library shell run per keypress. Basis: src/compsys/README.md (rkyv-mmap hot path, parallel rayon compinit); autoload_cache.rs (16k+ autoload bytecodes bulk-committed). Caveat: overlaps #14 but completion-specific.

zsh's compsys is reimplemented in Rust (~128 files / ~22k LOC mirroring zsh Completion/) and driven outside an interactive shell so an LSP surfaces the same matches a Tab press would, with no subshell spawn. Basis: src/compsys/ported/; src/compsys/in_editor.rs:256 complete_at; LSP wiring lsp.rs:1723 (compsys dispatch inside the completion flow) → try_compsys_completion (lsp.rs:1746); tests/compsys_backend_proof.rs. Caveat: Phase 0.5 / unproven end-to-end — no per-command completer (_git/_kubectl) ported yet, in-editor smoke test yields zero matches (no compinit bootstrap); framework real, content WIP.

zsh's completion system (compsys — compinit/compdef/the _* completer machinery), historically reachable only from inside a running zsh, is reimplemented in Rust (~47,000 LOC) and exposed as a public module of the importable zshrs crate (pub mod compsys), so any Rust program can compute zsh-grammar completions in-process — no interactive shell, no subshell spawn. Basis: zshrs/src/lib.rs:59 pub mod compsys; src/compsys/ (~47k LOC across in_editor::complete_at, router, cache, ported/); builds on #27/#28 (the compiled + in-editor compsys). Caveat: compsys is a public module of the zsh crate, not a separately-published crate; per-command completer content parity is still WIP (see #28); "watershed"/"first" is the author's own assertion pending a prior-art sweep.

The shell mirrors its internal tables (aliases, _comps/_services/_patcomps, zstyles, functions, executables, autoloads, hooks, plugins, entry stats) into queryable SQLite views so the operator can run SQL / dbview against shell state — without those rows affecting execution or cache semantics. Basis: compsys/README.md §0x04; dbview builtin in ext_builtins.rs; daemon/catalog.db schema; canonical.rs hydrate_sqlite_view. Caveat: explicitly inspection-only.

Emits any subsystem's full canonical state as eval-compatible shell source with a wipe prefix, so eval $(zcache export <target>) resets aliases/path/functions/_comps/ zstyle/bindkey to canonical in the live process — no parser, no importer, preserving $$/fds/cwd/history/jobs. Basis: docs/DAEMON.md "Universal cache dump/export/view" (zcache export aliases → unalias -m '*' + re-alias; --additive); daemon/ops.rs/export.rs (82 KB). Caveat: round-trip fidelity depends on canonical capture completeness.

Saves portable rkyv snapshots of canonical state, lists and reloads them by tag, and structurally diffs two snapshots per-record (added / removed / changed) — git-like state archaeology for a shell environment. Basis: daemon/snapshot.rs — snapshot_save (:81), snapshot_list (:139), snapshot_load (:178), snapshot_diff (:323), stored at ~/.zshrs/snapshots/<tag>.rkyv; DAEMON_AS_SERVICE.md. Caveat: there is no bisect op — bisecting to the first diverging record is described in the module header but not implemented; the shipped surface is save/list/load/diff only. v1 also defers publish/sign/verify and registry transport.

Shell-native parallel primitives (async/await/pmap/pgrep/peach/barrier) compile to bytecode and run on a persistent warm thread pool, replacing the fork(2)-per-subtask model (completion runs, command/process substitution) with bounded crossbeam dispatch — no address-space duplication. Basis: src/extensions/worker.rs (crossbeam pool, available_parallelism() clamped [2,18], 4×N backpressure, catch_unwind per task; doc contrasts zsh's zfork()/forklevel). Caveat: async/await as shell keywords overlap other languages; novelty is the zsh-superset surface + no-fork execution.

Decodes zsh's native compiled .zwc wordcode and emits a canonical AST S-expression so zshrs's parser output can be byte-compared against zsh's own bin_zcompile() output — a verifiable parser-parity oracle. Basis: src/extensions/zwc_decode.rs (43 KB) + zwc.rs (60 KB) + ast_sexp.rs → tests/parity/parity_harness.rs. Caveat: verification infrastructure, not a user-facing capability.

fish's interactive trio — token-classification syntax highlighting, history-driven ghost-text autosuggestions, and history-backed suggestion search — reimplemented inside a non-fish shell's own binary, adapted from fish-shell's Rust codebase, rather than layered on as interpreted userspace plugins (zsh-syntax-highlighting / zsh-autosuggestions reimplement these as zsh script and pay interpreter cost per keystroke). Basis: zshrs/src/extensions/fish_features.rs (953 L; HighlightRole adapted from fish's parse_constants::HighlightRole, highlight_shell token classifier, autosuggest_from_history, validate_autosuggestion, plus fish abbreviations and kill ring); in-module tests; re-exported at zshrs/src/lib.rs:323; zshrs's ZLE separately honors the plugin-side contracts ($POSTDISPLAY ghost text, region_highlight — zle_refresh.rs:1225,4456). Caveat: implemented and test-verified but not yet wired into the live ZLE keystroke path; "history search" today is the suggestion-search engine, not a ported fish Ctrl-R pager; "first" rests on non-exhaustive prior-art absence.

mark($x) tags a value's heap Arc so subsequent operations accumulate a lineage record retrievable via provenance($x) — automatic dataflow lineage exposed as a user verb, zero-cost when unused. Basis: provenance.rs (469 L), framed "no existing scripting language ships this". Caveat: lineage accrues only for marked values; op coverage breadth unverified.

hide(carrier, secret[, key]) auto-detects carrier type — PNG LSB embed in RGB channels or zero-width-char text encoding (U+200B/U+200C) — with a self-describing wire format (CRC framing + key-XOR) for reveal. Basis: stego.rs (412 L). Caveat: two carrier kinds only; LSB stego is not cryptographically robust.

Bloom filter, HyperLogLog, count-min sketch, etc. ship as first-class %b builtins next to set/deque/heap, Arc<Mutex>-wrapped for safe use under parallel iteration. Basis: sketches.rs (3,479 L), framed world-first-as-stdlib vs pyprobables/bloom-filters npm. Caveat: the algorithms are well-known; the claim is "as stdlib primitives".

A --compat mode pinning behavior to upstream Perl 5, specified by a ~20,000-test parity corpus, on a JIT'd runtime — claimed 2nd-fastest single-threaded dynamic language (behind LuaJIT) and fastest multithreaded. Basis: docs/patent.md Patent D #20; examples/rosetta/README.md (beats perl5/Python/Ruby/Julia/Raku, beats LuaJIT on 3 of 8); parity/; English.pm aliases english.rs; C3 MRO mro.rs. Caveat: the 20,000-test count and benchmark numbers are claims, not independently re-verified here.

god EXPR dumps heap pointer, Arc strong/weak counts, payload size, and generator/pipeline/closure-capture internals with cycle detection; complemented by nine compile-time-populated globally-named introspection hashes (%b/%all/%k/%a/%pc/…) giving O(1) bidirectional name↔callable indexing under the invariant %all = %a + %b + %k. Basis: god.rs (336 L); the name→category table is include!()'d from OUT_DIR/reflection.rs at builtins.rs:53, with the "reflection"-tagged entries (%a/%all/%b/%k/…) starting at builtins.rs:614; patent.md D #17. Caveat: the disjoint-union invariant wasn't independently re-verified.

docs/reference.html and the interactive stryke docs browser are generated from one in-code corpus (lsp::DOC_CATEGORIES + doc_text_for), so hover-docs, the terminal pager, and the static HTML site never drift. Basis: bins/gen_docs.rs (cargo run --bin gen-docs), doc_render.rs, docs.rs. Caveat: each piece (LSP hover, doc-gen) has prior art; the single-source unification is the novel bit.

web_* builtins (serve, ORM web_db_*, chainable models, migrator) provide a Rails-style DSL whose generator emits a full-stack app, intended to AOT-compile to a single static binary on thread-per-core io_uring. Basis: web.rs (3,952 L) + web_orm.rs (1,880 L, SQLite-backed ORM/migrator); stryke_web/ generator; docs/WEB_FRAMEWORK.md. Caveat: HTTP/2, glommio/io_uring, SIMD parser deferred to "Phase 2+"; ORM is SQLite-only.

A Cargo/uv/Nix/Bundler/npm-synthesis package manager (s CLI: init/add/build/ publish) with TOML manifest, hash-pinned lockfile, content-addressable store, and per-package-scoped features, whose s build --release AOT-compiles user code + every dep + stdlib through Cranelift to one static binary. Basis: pkg/ (manifest.rs/lockfile.rs/resolver.rs/store.rs/commands.rs); docs/PACKAGE_REGISTRY.md; bins/s.rs. Caveat: the "compile every transitive dep to native" feature depends on the still-WIP whole-program native path; registry maturity unverified.

A complete two-view arranger (Arrangement + Session, clips, breakpoint automation, tempo/meter maps) shipping standalone, as a VST3 inside another DAW, and embedded in arbitrary hosts — designed to drive even non-audio ones off the same clip/automation timeline. Basis: zpwr-daw app + zpwr-clip-engine; editor/arranger/automation verified. Caveat: "None found", not proven (see analysis). The audio render path is written but unverified (pending JUCE build). The non-audio embeds are wired today: traderview vendors zpwr-clip-engine as a submodule at frontend/vendor/zpwr-clip-engine and registers the engine's Tauri commands (clip_seq_pattern, clip_seq_transport, clip_seq_play, clip_seq_step, clip_seq_poll_events, clip_seq_export_midi) in traderview/src-tauri/src/lib.rs:492-497; ztranslator lazily imports vendor/zpwr-clip-engine/webui/clip/clip-seq.js and calls initClipSeq() from ztranslator-core/frontend/ztranslator_view.js:1235-1258. What remains unproven is depth, not presence — these hosts mount the clip/arranger surface but do not yet drive their domain objects (trades, translation events) off the timeline end-to-end.

Not a fixed channel-strip mixer with a modular device bolted on, but a DAW whose entire signal path is a user-patchable graph — every track auto-owns a layer, each layer is a stereo patch graph hosting oscillators/FX/VST3-AU plugins, the synth panel and mod matrix are generated from that same patch, and master/aux/global-mod buses are themselves patch graphs. Basis: zpc::StereoGraph (PatchEngineT<StereoSample>) + native stereo Plugin host, shared across all four products; per-track stereo graphs wired into the daw. Caveat: "None found", not proven (see analysis). Modular audio render (per-track graphs → master mix) is in progress / partially unverified — graph/wrapper/stereo-block are compile-verified; full per-track audio + cue bus still being wired.

A real interactive shell running inside the DAW (the MenkeTechnologies stack — zshrs/stryke), not a constrained scripting console, for driving the shell/CLI from within the project. Basis: part of the zshrs/stryke ↔ daw integration. Caveat: "None found", not proven; in progress, recorded ahead of completion. Scripting consoles exist (ReaScript, Max), but a full embedded interactive shell terminal in a DAW has no clean prior art found.

stryke embedded as a first-class scripting layer wired to every DAW lifecycle hook (load/save/transport/clip/track/render) and able to drive the GUI itself (interface automation, not just audio params). Basis: part of the stryke ↔ daw integration. Caveat: "None found", not proven; impl WIP. Reaper ReaScript / Bitwig controller scripts expose some actions, but a language bound to all lifecycle hooks and GUI automation has no clean prior art found.

Built from the ground up so the modular graph + embedded scripting + generative engine produce a finished, professionally-mixed track from a single action — generation as the primary workflow, not a loop-pack assist bolted onto a linear DAW. Basis: generative engine (zpwr-algo-production, 282 tests) linked over a C ABI; the PRODUCE tab generates a full arrangement in one click with chooseable output (.zdp or Ableton .als). Caveat: "None found", not proven. Auto-mix/master polish is maturing.

21 blocks are full instrument networks — Extended Karplus-Strong waveguide strings + modal resonator banks + bidirectional string↔body coupling — so sympathetic resonance and attack transients emerge from the physics. Basis: PhysicalModel.h (20 tech="physical" tags) + Physical.h (1) = the 21 PHY badges in BLOCKS.md. Caveat: physical modeling is a known field; novelty is offering coupled string/body networks as drop-in patch blocks.

A large family of sound/sequence generators driven by pure mathematics — Abelian sandpile, abundant/Achilles/Harshad number gates, Collatz/Fibonacci/prime sequences, Game-of-Life / Langton's-Ant / Brian's-Brain CA, strange attractors and chaotic neuron maps — as first-class audio and MIDI blocks. Basis: NovelBlocks.h, AudioModules.h; 365 blocks self-described "a first as a synth block". Caveat: scattered math-music mappings exist in research/Reaktor patches; the systematic registry library is the claim.

The modulation matrix is not a separate fixed grid — every node carries a float scalar projection of its output and every node parameter exposes a (source, depth) mod slot, so any block is automatically a modulation source for any parameter. Basis: PatchCore.h / src/PatchCore.cpp (mod-matrix eval, per-node scalar projection); README [0x00]. Caveat: modular synths inherently allow mod-from-anywhere; the explicit per-node-scalar-projection formalization is the distinctive engineering.

A "Stereo" toggle mirrors an entire mono patch (every block, cable, mod) into an independent right-channel clone chain (node j′ = j + N, reading In R where the original reads In L), auto-re-mirrored on every structural edit, with an optional "Lock" linking L/R knobs. Basis: zpwr-patch-core README [0x03] (stereoize/stripStereo/stereoSync/ NodeDef::clone/reconcilePresetModes). Caveat: audio-host only; an editor/graph transform, not a new DSP capability.

Any selection of blocks (with internal cables, mods, tempo-sync) saves as a self-contained reindexable .zmod sub-graph that splices into any patch and degrades gracefully across hosts, shared through a static git-backed JSON registry with no server (PR-based publishing). Basis: PatchCore.h (extractSubPatch/spliceInsert/ModulePorts); README [0x05] (.zmod, registryUrl, listModules/saveModule/importRegistryModule). Caveat: Phase 1 splices modules into real blocks (no nested-block encapsulated playback yet).

A VCV-Rack/Reaktor-Blocks-lineage synth with no fixed signal path: the user-built patch graph is instantiated as each voice across a polyphonic pool, with Scala microtuning applied as a fractional-note external so every oscillator inherits the tuning. Basis: zpwr-synth/README.md [0x00]/[0x01] (zsynth::PolyEngine → zpc::RuntimeGraph per voice); dsp/SynthModules.cpp; Scala.h. Caveat: modular synths exist (VCV, Voltage Modular); novelty is sharing the exact graph core with the FX/MIDI/DAW products.

The DAW's pattern→events→transport/MIDI scheduler is extracted as a header-only pure-C++17 engine that compiles two ways from one source (a static .a the DAW links natively and a .dylib/.so Tauri apps load via Rust FFI), paired with one JS canvas grid whose domains (arranger/notes/launcher/automation) are reused verbatim by every GUI app, with a non-audio JS fallback backend. Basis: zpwr-clip-engine/README.md (engine/include/zpc/ClipEngine.h, engine/include/zpc/capi/clip_engine.h zpc_clip_*, the shared + static targets in engine/CMakeLists.txt:18,21, webui/clip/clip-seq.js, webui/clip/clip-basic-backend.js). Caveat: the Tauri FFI wiring "lands in steps"; several commands are no-ops in non-DAW hosts.

Standard MIDI File export is implemented twice (native C++ MidiFile.h and JS export/midi.js) and produces byte-identical output, so a project exports identically whether driven by the native engine or the browser fallback. Basis: zpwr-clip-engine/.../MidiFile.h + webui/grid/export/midi.js; tests under webui/grid/tests/. Caveat: a parity guarantee asserted in docs/tests, not independently re-verified.

A desktop app that maps every VST2/VST3/AU/CLAP plugin, reads each binary's architecture (ARM64/x86_64/Universal) by directly parsing Mach-O/PE headers, indexes sample libraries and DAW project files with header-extracted metadata, and checks KVR for newer versions with a persistent scan changelog. Basis: Audio-Haxor/README.md [0x01]/[0x09]; src-tauri/src/audio_extensions.rs, crates/zpwr-crate. Caveat: a cross-platform asset/plugin manager; "no other does this" not proven.

A Docker-Desktop replacement that provides its own dockerd by booting a Linux guest directly on macOS Virtualization.framework (objc2-virtualization) — no vfkit/limactl/qemu/Colima binary and no Docker Desktop dependency. Basis: zcontainer-core/README.md "Daemon management": src/daemon.rs, src/vm.rs (vm feature), scripts/build-guest-image.sh (Kata VZ kernel + Alpine/dockerd rootfs + vsock bridge), socket proxy to ~/.zcontainer/run/docker.sock. Caveat: the managed-VM path requires a signed tauri build (com.apple.security.virtualization); an unsigned build reports vm_runtime_unavailable, so end-to-end self-hosting isn't verifiable from a dev build.

A BOME-MIDI-Translator-class engine whose Outgoing layer fans far beyond MIDI/keystroke into a large protocol matrix — OSC, Art-Net/DMX, sACN/E1.31, MQTT, WebSocket, raw TCP, HTTP, Ableton Link, eurorack CV/gate (DC-coupled audio), MTC/MMC/RTP-MIDI, gamepad rumble, HID — all from one rules VM, embedding into non-MIDI Tauri hosts. Basis: ztranslator/README.md Outgoing-actions table (backends rosc/rumqttc/tungstenite/rusty_link/cpal/gilrs), rules.rs integer VM, tauri/ plugin + frontend/ztranslator_view.js mountZTranslator. Caveat: PORT_REPORT self-reports 71.9% BOME coverage (ztranslator/PORT_REPORT.md:9, weighted full=1 / partial=0.5 over 73 features); OS-control + CV/gate are macOS-only.

A clean-room importer/exporter for BOME MIDI Translator Pro .bmtp projects that round-trips losslessly — undecoded encodings (MID1, KAM1, mouse, serial) are preserved verbatim so a project survives re-export even when individual entries aren't yet natively understood. Basis: ztranslator/README.md §0x03; bmtp/ module; Outgoing::Raw. Caveat: export is unsigned (no RSA signature), so signed BomeBox/MT-Player export is out of scope.

A trading journal shipping two binaries from one Rust workspace — a Tauri desktop app that downloads/runs an embedded PostgreSQL on first launch (auto-login, offline) and an axum web server on external Postgres (argon2+JWT) — sharing crates, schema, migrations, FIFO roll-up, and verbatim frontend. Basis: traderview/README.md §0x01-0x03; postgresql_embedded (~/.theseus), shared traderview-{core,db,import}; src-tauri holds Embedded across axum::serve. Caveat: dual-target embedded/external DB patterns exist generally; the specific novelty is modest.

A trading journal bundling a no-cloud/no-LLM receipt + IRS-form OCR pipeline (Apple Vision/ Tesseract/PaddleOCR ensemble, W-2 / 1099- / 1098 parsers, 20-bucket Schedule C taxonomy) feeding a dependency-light US federal tax compute engine pinned to IRS Rev. Proc. 2024-40 with 218 unit tests. Basis: traderview crates — traderview-ocr (5.2k LOC), traderview-expense, traderview-tax (6.6k LOC; 5 deps — serde, serde_json, rust_decimal, chrono, thiserror). Caveat:* the notable part is integration ($0/receipt, on-device) inside a trading app; test counts/LOC are README-reported.

A trading journal embedding the stryke language's JIT as its backtest/strategy engine — JIT-compiled backtests, a walk-forward sweeper, a custom-indicator AST, and strategy alerts gated by optional stryke predicates with webhook payload templating. Basis: traderview/README.md §0x00 + traderview-core ("stryke-JIT backtest engine + walk-forward sweeper… custom-indicator AST"), traderview-stryke host bridge running stryke lifecycle hooks as sandboxed subprocesses. Caveat: an application of the fusevm/stryke runtime (#1); engine maturity not build-verified.

258 framework-free window.ZGui.* components (one per webui/*.js file) — including DAW-grade controls (rotary knob, 88-key playable piano, modular patchbay with drag-to-connect bezier cables, ADSR/LFO/curve editors, dB faders, peak/LUFS meters) alongside tables, modals, charts, and shell chrome — consumed by submodule (never copied) as the single UI source across a whole suite of unrelated desktop apps (terminal, mail, FTP, PDF, container, trading, translator…). Basis: zgui-core/README.md (full webui/ table) + CONSUMERS.md (submodule-only rule). Caveat: shared component libraries aren't novel; the unusual part is one cyberpunk kit carrying both business-app widgets and synth/DAW hardware controls as plain static JS with no build step.

A mandatory ZGui.appShell baseline (splash, ⌘K palette, rebindable shortcuts, settings, native OS menu) plus a headless render gate that fails any app's build if the baseline stamp/chrome or submodule placement is missing — mechanically enforcing one UI across the suite, with auto-installed Emacs/readline editing on every <input>/<textarea>. Basis: zgui-core/CONSUMERS.md §0 (appShell, scripts/baseline-gate.mjs, dataset.zguiBaseline, placement assertions), util.js. Caveat: a discipline/tooling invention, not user-facing.

One Chrome MV3 extension unifies a pass/browserpass-compatible vault (profile + credit-card autofill), a segmented multi-connection download accelerator, a JetBrains-style MRU tab switcher, fzf history, a Tampermonkey-equivalent userscript engine, full-page screenshot stitching, and a Wappalyzer-compatible detector over a vendored 3,993-fingerprint corpus — all backed by a single pure-Rust native-messaging host. Basis: zpwrchrome/README.md + zpwrchrome-host (Rust port of browserpass-native v3.1.2 + otp/search/dl.*, ureq+ rustls); 3044 JS + 127 Rust tests; lib/wappalyzer/engine.js. Caveat: each capability replaces a known tool; novelty is consolidation + a single static Rust host.

A multi-connection (Range-segmented) download accelerator in a vendorable pure-Rust host (no aria2/axel binary) that intercepts every Chrome download by default, with truncation/premature-EOF detection, resume, cookie+UA forwarding, and a byte-count completion gate. Basis: zpwrchrome/README.md "Segmented download accelerator" (zpwrchrome-host dl.*, HEAD probe → N concurrent Range GETs, pre-allocated dest). Caveat: download accelerators are a known category; the angle is doing it as the default handler from a single Rust host.

A native desktop GUI that wraps the zmax Rust Emacs modal IDE by running it in an embedded PTY and driving it purely through ex-commands, with every GUI surface (menubar, toolbar, palette, dialogs, file tree) built from zgui-core. Basis: zmax-gui/README.md — zpwr-embed-terminal PTY, open_intake.rs (mvim:// deep-link → :open), bundled zmax+stryke sidecars, and the frontend/ layer (main.js, panels.js, fb-backend.js, tmux-config.js) driving zgui widgets → PTY. Caveat: the "wrap-a-CLI-editor-in-a-window" pattern is MacVim; novelty is doing it for a new Rust Emacs entirely through a shared web widget kit + PTY.

An in-app "Processes" tab renders a live CPU/MEM process tree rooted at every pane's shell — including descending into the tmux server's reparented children — and can signal/kill only pids that are descendants of its own panes. Basis: src/event.rs pane_process_tree() builds a ppid→children map from a sysinfo snapshot, seeds roots from wc.pane_shells() + ztmux_core::ops::panes() pids (labeled tmux <s>:<w>.<p>); "kill_process" IPC arm gates signals to the seen descendant set. Caveat: Unix-only; an inspector, not a top replacement.

Editing an env var in the control panel both persists it to [env] in zterminal.toml and live-broadcasts export NAME=value / unset NAME into the PTY of every already-running shell across all panes, so it takes effect without relaunching. Basis: src/settings.rs save_env_var()/delete_env_var() (toml_edit) then EventType::BroadcastInput; export_command() POSIX-single-quotes + leading space (to dodge HISTCONTROL=ignorespace); window_context.rs broadcast_input(). Caveat: injects a shell command — affects shells at a prompt, not arbitrary child programs.

Reimplements tmux-resurrect/continuum natively over tmux's binary wire protocol — snapshotting every session→window→pane with exact window_layout, cwd, and the pane process's full captured command line, then rebuilding the tree, optionally relaunching processes (resurrect-style whitelist) and replaying saved pane scrollback, with opt-in auto-restore on launch. Basis: crates/ztmux-core/src/snapshot.rs (<name>.json + <name>.contents/); proc.rs reads each pane's foreground command line natively (libproc KERN_PROCARGS2 / /proc, no pgrep); src/event.rs resumed() fires restore(...) off-loop; overlay ⌃⌘S. Caveat: live process state can't be restored (panes return as fresh shells with the command replanted); resurrect as a concept is prior art — the novelty is doing it natively over the wire from an emulator.

A broadcast overlay sends keystrokes (or snippets) to an arbitrary checked set of tmux panes spanning any windows and sessions at once — which native tmux can't do, since synchronize-panes is scoped to a single window. Basis: crates/ztmux-core/src/ops.rs broadcast_list() + send-keys toggle; src/settings.rs open_tmux_broadcast() + "tmux_broadcast_list" / "snippet_broadcast" arms; ⌃⌘B. Caveat: requires a running tmux server.

zterminal's entire configuration/inspection surface (Settings, Dashboard, tmux, Keybindings, Logs, About, command palette, every overlay) is a single-binary in-process webview app built only from zgui-core, served over a custom zterminal:// protocol — a terminal whose whole control plane is a reusable design-system app, not native dialogs or a TUI. Basis: src/settings.rs embeds settings/frontend + zgui-core/webui via include_dir!, injects an IPC_BRIDGE (window.__ztermInvoke → wry postMessage → Rust dispatch()); same ZGui.fzf powers palette, history, and cross-pane search. Caveat: the dashboard sub-piece is already captured (#104); this is the broader umbrella.

strykelang ships a 32-package first-party connector ecosystem spanning cloud (AWS/GCP/Azure), orchestration (Docker, k8s), messaging (Kafka, ZeroMQ), 9+ databases (Postgres/MySQL/MSSQL/ Mongo/Redis/Scylla/Neo4j/ClickHouse/DuckDB), columnar (Arrow/Parquet/Polars/Spark), search (Elasticsearch/OpenSearch), gRPC, browser/GUI automation, office I/O, and MCP — breadth of native data/cloud connectivity not previously offered for a Perl5-lineage language. Basis: 32 stryke-* dirs; stryke-demo/README.md package matrix (which lists only 14 of them) + single s install; 31 of the 32 READMEs carry the [stryke-package] badge (stryke-app has none). Caveat: "first for a Perl5-like language" is a framing claim; tiers vary in maturity; breadth, not any single deep integration, is the novelty.

Several connectors are pure-.stk packages (zero FFI table, zero cdylib, zero helper binary) adding production policy on top of capabilities the language exposes as core builtins — connector-as-pure-library. Basis: stryke-fleet/stryke-mcpd have rust=0, stk=11 each; READMEs state "no [ffi] table, no cdylib, no helper binary — just .stk modules on use ..."; wrap core pty_*/pmap, mcp_server_start. Caveat: novelty depends on the core shipping those builtins; the packages are orchestration/policy.

Author Model Context Protocol servers that compile to one static native binary, eliminating the Node runtime / Python venv current MCP servers drag onto the target. Basis: stryke-mcpd/README.md; Mcpd::Schema/Server/Tools/Client; core mcp_server_start; stdout-purity test. Caveat: Rust/Go MCP SDKs also yield static binaries; the distinctive part is MCP authoring in this Perl5-like language.

Reads and writes the full office suite — Excel/ODS, Word/ODT, PowerPoint/ODP, PDF — entirely in native Rust with no soffice/LibreOffice/pandoc subprocess and no external install. Basis: stryke-office/README.md; ~51k LOC across 17 src files incl. pptx_write.rs, pdf_build.rs, pdf_form.rs, chart_render.rs, barcode.rs. Caveat: "entirely native" likely means a curated feature subset; fidelity vs LibreOffice unverified.

A Rust lsof reimplementation headlining 5–21× faster process↔file/socket mapping, adding JSON/CSV output, watch/leak-detection modes, and an interactive TUI classic lsof lacks. Basis: lsofrs/src/{darwin,linux,freebsd}.rs, net_map.rs, tui_app.rs, leak.rs, monitor.rs; ~23.5k LOC; on crates.io. Caveat: the 5–21× figure is self-reported; speed/UX, not a fundamentally new capability.

A native single-binary Rust port of Python powerline-status that is drop-in compatible with existing powerline/config themes and eliminates Python's ~50–150 ms per-render interpreter-startup tax, validated by 462 parity tests that run the upstream Python interpreter and assert byte/value-identical output. Basis: powerliners/src/ported/, src/extensions/, src/bin/; 134/137 upstream .py files DONE (97.8%); 2473 lib tests; per-line // py:NNN citations. Caveat: a faithful port; novelty is the engineering rigor + perf win, not new functionality (powerline-go exists but isn't a byte-parity port).

A from-scratch Rust reimplementation of the Zotero reference-manager engine (37 item types, CSL processor, BibTeX/RIS/CSL-JSON/EndNote/MODS/MARCXML/RDF I/O, DOI/ISBN/PMID/arXiv lookup, dedup) extracted as one engine (rlib/staticlib/cdylib + C ABI + header-only C++ wrapper + mountable webui) so the same citation engine embeds inside other GUI apps. Basis: zcite/crates/zcite-core/src/{schema,model,store,search,bib,csl,import,export,identifier,pdf, duplicates,webdav,zotero,ffi}.rs; include/zcite_core.{h,hpp}; webui/; zcite/crates/zcite-core/PORT_REPORT.md:9 self-assesses 96.6% weighted Zotero coverage (82 full / 6 partial / 0 missing over 88 features, plus 4 out-of-scope). Caveat: "in development"; a reimplementation of Zotero — the novelty is the embeddable-engine packaging.

zmax embeds ten scripting interpreters — Emacs Lisp, Vimscript, AWK, zsh, stryke, Ruby, PHP, Python, JavaScript (Node), and arb — directly compiled into the binary with no external process and no C-ABI/FFI between them, all driving the live buffer through one uniform host API. Basis: zmax/README.md:86-87 ("the only IDE to embed 10 scripting languages with zero external dependencies and no FFI between them"); book/src/scripting.md (:elisp/:vim/:awk/:zsh/:stryke/:ruby/:php/:python/:node/:arb, SPC a r unified REPL); each is a pure-Rust crate lowering onto shared fusevm bytecode. Caveat: overlaps #1 (the IDE-embedding angle of the same crate family); "world first" is the repo's own assertion; each interpreter exposes only a subset of its host API.

One language-agnostic editor "host ABI" lets interpreters that expose only bare fn pointers with thread-local state mutate the live document, by publishing the in-flight compositor::Context through a type-erased thread-local pointer installed by an RAII guard for one synchronous on-thread eval, with a guard stack for nested evals. Basis: zmax-term/src/commands/scripting/mod.rs (CX_PTR thread-local, CxGuard RAII, with_cx; api_insert/api_goto_char/api_delete_region build undoable Transactions); SCRIPTING_EMBED_PLAN.md §2.1. Caveat: the architectural substrate of #120, recorded separately as a distinct mechanism; unsafe, single-thread-only.

A single REPL panel fronts all ten embedded interpreters (elisp/viml/stryke/awk/zsh/ruby/php/python/node/arb) behind one read-eval-print loop, cycling the active language with Tab and persisting separate input histories per language to ~/.zmax/repl-history.toml. Basis: zmax-term/src/ui/repl.rs (660 L, ReplLang enum, transcript scrollback); opened via :repl [lang] / SPC a r. Caveat: part of the captured scripting story; the one-panel-many-languages REPL with per-language persisted history is the distinct artifact.

:awk <prog> runs an embedded AWK interpreter over the current selection (or whole buffer) and replaces it with the captured output as a single undo step, in-process with no external awk. Basis: zmax-term/src/commands/scripting/mod.rs::run_awk_filter (runs awk::run outside any editor borrow, applies one Transaction); commands/scripting/awk.rs. Caveat: piping a selection through external awk (!awk) is a classic vi idiom; the novelty is the in-binary interpreter wired as an undoable in-place filter.

A native JetBrains-style three-pane (ours/result/theirs) conflict resolver with a diff3 base pane, inline char-level highlighting, per-block resolution, and a recomputed live Result pane written back as one undoable transaction. Basis: zmax-term/src/ui/merge.rs (2211 L, imara_diff, DiffRow/Block/Resolution); :merge/:diff, ]n/[n. Caveat: 3-way merge tools are common standalone; embedding one as a terminal overlay in a modal editor is the novel part.

A magit-style interactive git porcelain (sectioned status, per-hunk staging, interactive rebase, branch/stash menus, commit-log + per-commit diff, ahead/behind counts) as a built-in terminal overlay. Basis: zmax-term/src/ui/magit.rs (3162 L, parse_status unit-tested, stage/unstage/discard/commit, MagitLog/MagitShow); :magit/:git/:gst. Caveat: Magit (Emacs) and porcelains (lazygit) are prior art; novelty is native-Rust and built into this editor.

An org-mode subset (outline folding, TODO cycling, capture) plus a date-aware agenda that aggregates TODO/DONE headings from all open .org buffers and a shallow filesystem walk, bucketing Overdue/Today/Upcoming with a dependency-free date model. Basis: zmax-term/src/ui/org_agenda.rs + commands/org.rs (24 KB, parse_agenda/today unit-tested); :org-agenda/:agenda, :org-capture. Caveat: Org-mode is canonical Emacs; this is a native reimplementation of a slice (babel/export/recurring deferred).

Binary files a text editor would reject instead open automatically in a built-in xxd-style hex editor backed by a raw Vec<u8> (not the text rope), with nibble/ASCII overwrite editing and byte-faithful round-trip on save. Basis: zmax-term/src/ui/hex.rs (720 L; raw-byte backing, Ctrl-s writes via std::fs::write); CHANGELOG ("binaries now open here instead of being rejected"). Caveat: hexl-mode/standalone hex editors are prior art; novelty is the auto-routing-on-binary-detection in a modal editor. Overwrite-only (no length change).

Real PTY-backed shells in editor panes (vt100-parsed grid blitted to the surface) with its own C-\ window-leader for split/focus and click-to-focus across panes — a small terminal multiplexer living inside the modal IDE. Basis: zmax-term/src/ui/terminal.rs (portable_pty + vt100, background reader thread, F12 detach); :terminal/:term, SPC p '. Caveat: integrated terminals exist (Emacs/VS Code); the multiplexer-style window leader + per-pane PTY in a modal editor is the addition.

A JetBrains-style workbench renders inside the editor view — project file tree, tree-sitter structure outline, problems/run panels, right-hand error-stripe minimap — entirely from in-process editor state (no PTY bridge), with the whole layout (drawer widths, folds, hidden panels, minimap, colorscheme) persisted to appdata and restored. Basis: zmax-term/src/ui/ide.rs (5451 L), file_tree.rs, run.rs (live console with ANSI scrubbing), run_config.rs; :ide/:workbench/F2. Caveat: IDE chrome is common in GUI IDEs; doing it as a pure-terminal overlay fed only from editor state is unusual.

A CRUD snippet-library TUI whose bodies are validated against the LSP-snippet engine; typing a trigger + Tab expands with live ${1:…}/$0 tab stops, with user triggers taking priority over emmet abbreviation expansion and scoped per language. Basis: zmax-term/src/ui/snippets.rs (validates via zmax_core::snippets::Snippet, persists snippets.toml); emmet_expand/ snippet_expand. Caveat: yasnippet/LSP snippets are prior art; the integrated CRUD TUI + emmet-priority + LSP-syntax validation combo is the addition.

A labelled Spacemacs SPC command tree ported onto the zmax modal engine with which-key-style popups whose auto-display is tunable per-prefix (auto-info, auto-info-exclude), plus a frecency-ranked recent-file picker and a startify start screen. Basis: keymap/vim.rs SPACEMACS_TYPABLE table; docs/spacemacs_gaps.md (tracks 358/702 remaining); frecent_file_picker + ui/startify.rs. Caveat: which-key + Spacemacs leaders are Emacs prior art; the novelty is the native port onto its selection engine with per-prefix tunability and a gap-tracked coverage doc.

The in-editor Settings page is not a hand-maintained schema — it serializes the live editor Config to TOML on every render and exposes every leaf (typed bool/int/float/str/enum/raw-TOML), writing edits back to config.toml with live reload. Basis: zmax-term/src/ui/settings.rs (Kind/ENUMS cycle support). Caveat: auto-generated config UIs exist generally; a fully reflective settings TUI for a terminal modal editor is unusual.

zmax ships a Cursor-style AI assistant compiled into the IDE binary itself — bound to SPC a i, it sends the current selection (with language fence) as code context to a pluggable LLM backend (Anthropic default, OpenAI alternate) behind one Provider trait, runs the network call off the UI thread, and renders the reply in a scratch buffer — with no package to install, no external agent process, and no FFI. Anthropic is the default with ANTHROPIC_API_KEY, so a freshly-built binary is AI-capable out of the box. Basis: zmax-term/src/ai/{mod,anthropic,openai}.rs (the Provider trait + two vendor backends, ZMAX_AI_PROVIDER/ZMAX_AI_MODEL env config); ai_chat at zmax-term/src/commands.rs:12974 (selection→fenced-context prompt → scratch buffer, spawn_blocking off the UI thread); keymap binding zmax-term/src/keymap/vim.rs:1113 (SPC a i). Caveat: the terminal/Emacs-style + built-in, no-plugin framing is the angle — GUI editors ship AI built-in (Cursor, Zed, Windsurf), and Emacs/Neovim get LLMs via packages (gptel, copilot.el, avante.nvim, codecompanion), so this is "first CLI/Emacs-style IDE with the assistant compiled in," not first-AI-editor; "no prior art found" is non-exhaustive, not proven. It is also self-described Phase 1 — non-streaming single-turn chat; the streaming chat panel, inline edit, and autonomous agent are scaffolded in the module docs but not yet wired. A zmax addition.

Editor support (Emacs major mode, Vim/Neovim runtime, VS Code extension) for the zshrs shell whose syntax grammars/font-lock are auto-generated from the shell binary's own reflection tables (zshrs --dump-reflection) so they carry the complete builtin/extension surface and never drift, plus LSP (zshrs --lsp) and DAP (zshrs --dap). Basis: vscode-zsh/README.md:34-37 (grammar via gen_grammar.sh, standalone source.zshrs, 113 extensions own scope, DAP Implemented); vim-zsh/README.md:32 ("never drifts"); emacs-zsh/README.md (zshrs-mode, reflection-driven font-lock, lint via zshrs -n, eglot LSP). Caveat: the novel substrate is zshrs itself; these three are editor front-ends; reflection-driven grammar gen + shell DAP are the distinctive bits.

A single-author zsh framework that is simultaneously a namespaced zpwr <verb> CLI dispatcher (~460 verbs), a fully-wired zsh+tmux+vim/neovim+fzf cockpit, and an env-var control plane spanning the entire terminal. Basis: zpwr/autoload/common/zpwr dispatcher; DESCRIPTION.md:55 (460 verbs, 14,100 completions, 2,000 aliases, 190,000 LOC); README.md:47-49 positions vs Dotmatrix/famous dotfiles. Caveat: "category of one" is positioning, not prior-art-proven; oh-my-zsh/prezto/large dotfiles occupy adjacent space; counts self-reported.

A pure-zsh plugin that rewrites the spacebar into a live expander for regular/global/suffix aliases, typo corrections, globs, parameters, history, and command-substitution — parsing deep prefix chains (sudo/env/nice/…) to find the real command — and shows fish-style ghost text previewing what an alias would expand to before you press space. Basis: zsh-expand/README.md:73,115-127; ghost text in zsh-expand.plugin.zsh:419-420 (ZPWR_EXPAND_PREVIEW, zle-line-pre-redraw). Caveat: zsh-abbr/fish abbreviations exist; the distinctive bits are the ghost-text preview of alias expansion + deep prefix-chain parsing; test count self-reported.

Native REST trading clients + reconnecting WS fill-pumps for Alpaca/IBKR/Schwab/Tastytrade/Tradier/ Webull(RO), routed by a dispatcher that logs order intent and feeds fills into the roll-up. Basis: traderview-db/src/{alpaca,ibkr,schwab,tastytrade,tradier}_trading.rs + the five matching *_pump.rs (Webull is read-only and lives in traderview-db/src/webull.rs, with no trading/pump pair), broker_dispatcher.rs. Caveat: WIP — only Alpaca fully wired; others return integration_pending.

Institutional-style transaction-cost analysis in a retail journal: Almgren-style implementation- shortfall decomposition, VWAP-relative and per-symbol slippage, a fill-quality report, time-and-sales tape replay reconstructed per trade, plus named-setup attribution (win rate / expectancy / avg-R / profit factor by setup tag) and an R-multiple distribution report. Basis: traderview-core/src/ {implementation_shortfall,vwap_slippage,setup_catalog}.rs; traderview-db/src/{fill_quality,tape_ replay,r_distribution}.rs. Caveat: needs arrival-price/VWAP data per execution.

OTP codes are computed inside the extension via Web Crypto (HMAC-SHA1/256/512, RFC 6238/4226) directly from the stored otpauth:// URL, sidestepping both the pass-otp gpg extension and the Chrome-spawned-host PATH problem (where pass lives in a dir not on the host's launch PATH). Basis: lib/totp.js, tested. Caveat: a re-implementation; the delta is the dependency/PATH decoupling.

A Tampermonkey-equivalent built on Chrome 120+'s chrome.userScripts (USER_SCRIPT world + configureWorld), injecting a GM_* shim as prepended source, with a single-flight serial sync chain that defeats the "Duplicate script ID" race across concurrent registrations, plus auto-expansion of bare-host @match to *.host; falls back to webNavigation+scripting injection on older Chrome. Basis: background.js syncUserScripts, lib/gm-shim.js, lib/userscript.js. Caveat: GM_* is a subset; native mode needs the per-extension toggle.

A from-scratch JS reimplementation of every Wappalyzer matcher group plus implies/requires/excludes graph rewrites and \1 version backrefs, where all ~1,045 DOM-selector rules are evaluated in a single injected querySelector sweep keyed for O(1) lookup — fully offline in an MV3 service worker, no cloud call. Basis: lib/wappalyzer/engine.js; header capture via webRequest.onCompleted. Caveat: corpus vendored upstream; novelty is the offline MV3 engine + batched DOM pre-flight.

Captures off-screen content without the chrome.debugger permission (no "DevTools attached" banner) and eliminates repeated sticky/fixed banners purely by overlapping each scroll step by 200 px so the next tile overwrites them (no DOM mutation), then stitches on an OffscreenCanvas in the service worker. Basis: lib/screenshot.js. Caveat: scroll-capture is GoFullPage's approach; deltas are the no-debugger stance + the chunked write path (#149).

A host action streams payloads larger than Chrome's ~1 MiB host→extension cap by splitting base64 across N dl.writeFileChunk calls keyed by a sanitized sessionId, appending into a .part scratch file, then atomically renaming to the download dir — the mechanism that lets a multi-megapixel screenshot PNG land on disk at all. Basis: dl.rs dl_write_file_chunk + self-contained RFC 4648 base64. Caveat: reusable platform-limit workaround (overlaps #148).

Per-rule basename-glob→argv post-download automation executes via std::process::Command with no shell anywhere on the path, so {path}/{dir}/{name} substitution carries zero quoting/injection surface, gated by an optional Run/Skip confirmation that survives SW suspension, with captured output (64 KiB cap) and a timeout that kills runaways. Basis: zpwrchrome-host/src/extensions/ run_command.rs. Caveat: pipes/redirects require explicit bash -c.

Extracts CSL-JSON (Highwire citation_*, Dublin Core, OpenGraph, schema.org JSON-LD) and the host drops it as a plain file into zcite's inbox dir — computed with the same dirs crate zcite-core uses so paths agree — so the MIT extension/host act as a Zotero-Connector for a separate reference manager while sharing only a file format and a path, never linking the paid engine. Basis: lib/zcite- extract.js; zpwrchrome-host/src/extensions/zcite.rs. Caveat: needs zcite running.

Beyond porting JetBrains' Recent-Files UX, the tab switcher adds save/restore of named tab "scenes" (persisted across restart), an opener-tree forest reconstructed from openerTabId with iterative flatten (50k-deep chains without stack overflow), frecency re-ranking, and a domain-hue minimap. Basis: lib/util.js, background.js scene handlers. Caveat: individual features exist elsewhere (OneTab/Workona); novelty is bundling into the JetBrains-modal idiom.

zwire (a rebranded Chromium) ships tmux's full control model inside the browser driven by a prefix key (Ctrl-b, ⌥-b fallback) — not a two-pane "split view" but nested SESSION → WINDOWS → PANES with splits both directions to any depth, named windows, zoom, synchronize-panes typing broadcast, copy-mode, and detach — in two surfaces: an in-page iframe overlay where every pane is a real webpage (any site framed by stripping X-Frame-Options / frame-ancestors), and an OS-window tiling engine where panes are real browser windows tiled by chrome.windows geometry (cols/rows/main-v layouts), both fed by one prefix-key content script and surviving MV3 worker eviction via persisted state. The two are no longer independent implementations: the HUD's bespoke ztmux.js was deleted (commit cc46c47065) and the iframe engine is now the shared zgui-core tmux engine the rest of the stack uses. Basis: the shared engine zgui-core/webui/tmux.js (1,474 L — isPrefix() Ctrl-b/⌥-b at :125, toggleSync()/toggleSyncPane() at :286-287, nested tree splits, the C-b : command CLI + copy-mode), driven in the browser by zwire/extensions/hud-internal/ztmux-pane.js (252 L) + ztmux-config.js (88 L); zwire/extensions/hud-internal/background.js (1,396 L — TMUX window/pane model, tmuxCmd() split/nav, rectsFor() layouts, tile(), publishTmux() state persist); zwire/newtab/tmux-pane.js pane forwarder; the fork's 0008-allow-framing.patch (renderer_host/ancestor_throttle.cc) bypasses X-Frame-Options natively so any site frames into the N-pane tiling. (broadcastSync() no longer exists anywhere in the tree.) Caveat: "None found", not proven — a web survey found terminal multiplexers (tmux/Zellij) and browser tab-tiling / split-view features (e.g. Vivaldi), but no browser exposing the full tmux model (prefix key, named windows, sessions, nested splits, synchronize-panes) built in; the search is not exhaustive. Runs today as an MV3 extension on unbranded Chromium; the native fork patch is authored/apply-clean but the whole-chrome fork is an optional ~100 GB source build. synchronize-panes relays a semantic-token subset (printable keys + C-w/C-u), not arbitrary keystrokes.

zwire renders a real tmux-style powerline statusbar (full ►/◄ chevron segments, alternating shade blocks) fixed to the bottom of every web page, fusing tmux session state with live machine telemetry: LEFT shows the ZW signature, the C-b prefix block that lights when the multiplexer prefix is armed, active window/pane list, color scheme, VIM mode, and ⌘K; RIGHT streams real host stats from the native host — CPU · MEM · SWAP · DISK · IO · NET · LOAD · UP · TEMP · BATT · LAN · WAN · host · clock — themed by the active HUD scheme. Basis: zwire/extensions/hud-internal/zpowerline.js (72 L, registered at manifest.json:292) — the bespoke zstatus.js was deleted (commit cc46c47065) and this adapter now feeds the shared ZGui.powerline component from chrome.storage: zb_sys (native-host system stats), zb_tmux (window/pane segment + armed prefix lamp), zb_scheme/zb_ui (theme vars pushed onto :root so the bar paints in the active scheme + light/dark); telemetry from zwire/extensions/hud-internal/native/zwire-host/src/sysmon.rs (cpu/mem/load/net/temp via sysinfo). Caveat: "None found", not proven — browser extensions add status/stat bars, and terminal powerline bars are ubiquitous, but a tmux-powerline bar rendered on every page and wired to a browser-native multiplexer's live pane/prefix state has no prior art found; search not exhaustive. System segments are inert without the native host connected; top frame only, toggled via the ⌘K palette.

zwire ships zwire-host — a single native agent that recursively crawls the filesystem (fs_walk, capped, ext/depth/dirs-only/substring filters), runs subprocesses, watches/tails files, opens multiplexed PTY terminals, and exposes clipboard/notify/open + a small state store — usable as a serve NDJSON local-socket daemon, a one-shot call, and an embeddable Rust library (zwire_host::api::{walk, exec}). The same agent binary/crate backs three independent frontends unchanged: the zwire browser HUD (statusbar telemetry, pane terminals, the HOST-tab REPL), the zmax editor (auto-spawns zwire-host serve, no manual step), and the zpwrchrome extension host (zpwrchrome-host depends on the published crate and calls zwire_host::api for its host.crawl / host.exec actions). Basis: zwire/extensions/hud-internal/native/zwire-host/src/lib.rs (capability list), fsops.rs (fs_walk recursive crawl) + api.rs (walk/exec); zmax/zmax-term/src/commands/host.rs (client bridge, auto-spawn serve); zpwrchrome/zpwrchrome-host/Cargo.toml:52 (zwire-host = { version = "0.3", default-features = false } — a crates.io registry dependency, not a git/tag pin; the lockfile resolves 0.3.8 while the in-repo crate is at 0.3.14). Caveat: this is a filesystem crawler, not a web crawler — it walks local paths, not URLs. "None found", not proven: browsers ship single-purpose native-messaging hosts (password managers, download helpers), but a general filesystem-crawl + exec + watch + PTY host shipped with the browser and reused verbatim by an editor and an extension host has no prior art found; search not exhaustive. The daemon is a privileged local process (same trust model as any native-messaging host).

zwire ships a dedicated HOST page (a first-class HUD tab, reachable from the sidebar and the ⌘K palette) that is an interactive JSON-in / JSON-out REPL to zwire-host, the browser's native local process, over a persistent connectNative port: a resizable code editor for the request, a collapsible JSON-tree rendering of every reply and every streamed/pushed event, a catalog of the entire host command surface (49 commands — KV store, filesystem, fs_walk crawl, exec, background jobs, ps/kill, pub/sub bus, sysinfo, clipboard/notify/open, PTY, host peering — grouped and click-to-load), a live-tile view of the same statusbar telemetry the host streams, command history, and Save-As export of the whole transcript. The extension's own background service worker is drivable too — content-script palettes relay JSON to the worker (zb-host), which forwards to the host — and a user-defined host command type fires arbitrary JSON from anywhere in the browser. Basis: zwire/extensions/hud-internal/pages/host.js (+ host.html; chrome.runtime.connectNative, Z.codeEditor request editor, Z.jsonView tree log, the 49-entry command catalog, exportLog via chrome.downloads Save-As); native/zwire-host/src/session.rs (handle_cmd JSON dispatch); background.js zb-host relay; the host custom-command type in pages/commands.js + zpalette.js. Caveat: the REPL surfaces an already-existing protocol — the novelty is shipping an in-browser interactive console/REPL whose target is the browser's own native host + background worker (with a full command catalog + JSON-tree I/O), not the protocol itself. "None found", not proven: browsers expose DevTools consoles for page JS, and extensions ship native-messaging hosts, but an in-product REPL aimed at the browser's native + background processes has no prior art found; search not exhaustive. Same privileged-local-process trust model as any native-messaging host.

In zwire a ⌘K custom command is not a single action but a CHAIN of typed steps run top-to-bottom, each step independently one of url / browser-action (tab verbs) / color-scheme / js / shell / native-host JSON — authored in a per-step-typed CRUD wizard (each row its own type dropdown + value control + reorder ↑↓ / remove, ＋ Add step). One command can therefore chain, e.g., open-URL → set-scheme → run a shell command → send host JSON. The same command runs identically across three isolation contexts — web-page content scripts (worker bus), extension pages (direct chrome.tabs + native messaging), and the new-tab override — reconciled behind one entrySteps() model that also migrates the shipped single-{type,value} defaults. shell steps invoke the native host's exec (OS-selected cmd.exe//bin/sh -c), not a PTY, and toast the decoded output. Basis: zwire/extensions/hud-internal/pages/commands.js (the steps[] typed-step wizard — per-step type dropdown, reorder, entrySteps() migration); zpalette.js (content-script chain exec runCustom/runStep + runShell over the zb-host relay); pages/zg-boot.js (extension-page runCustomBoot/runStepBoot); newtab/palette.js (new-tab chain exec); palette-cmds.js (shared step-chain summary url → shell → scheme); background.js zb-host relay; native/zwire-host/src/exec.rs (exec program/args). Caveat: chaining sequenced actions is established in desktop launchers (Alfred workflows, Raycast, Keyboard Maestro, Automator) — the pattern itself is not novel. The first-ness is browser-native: no shipping browser (Chrome, Edge, Brave, Arc's Command Bar, Vivaldi Quick Commands) lets a user author a multi-step palette command, and none allow a palette entry to reach the OS shell — they are sandboxed to built-in single browser verbs. "None found", not proven; search not exhaustive. shell/host steps carry the same privileged-local-process trust model as any native-messaging host and are inert without the host connected (they no-op on the new-tab page, which has no host access).

zwire adds Output Triggers: a regex is matched against page text as it renders/streams and, on a match, runs the same typed step-chain as a ⌘K custom command (#168) — url / browser-action / scheme / js / shell / native-host JSON authored in the identical CRUD step wizard — but fired automatically by page content instead of a manual palette invocation. The matched line becomes {q} in every step; an optional URL-filter regex scopes which pages arm a trigger; a per-trigger cooldown (default 1500 ms) prevents a process storm on bursty output; shell/host steps reach the OS through zwire-host. This is explicitly the browser analog of a terminal emulator's "triggers" (iTerm2 / zterminal — regex on output → Run Command, e.g. open \0), moved off terminal scrollback and onto live web-page text. Basis: zwire/extensions/hud-internal/pages/triggers.js (full CRUD over chrome.storage.local 'zb_triggers'; matched-line→{q}, URL filter + cooldown; flags default i, g/y ignored, tested per line), the content-script engine ztriggers.js (compiles enabled triggers on every page and fires their chain through window.ZWIRE_CMD_EXEC exported by zpalette.js), and the shared pages/step-wizard.js that commands.js and triggers.js render identically (a command and a trigger are the same chain of typed steps). Shipped in v0.6.43. Caveat: the step-chain + CRUD wizard is #168's, shared not re-invented — the increment here is the trigger: automatic firing on regex-matched page content. Terminal emulators have exactly this (iTerm2 Triggers' "Run Command", zterminal's terminal triggers), so the concept is prior art in terminals; the first-ness claim is browser-native — no shipping browser was found that auto-fires an OS-reaching step-chain on page-text regex: Vivaldi Command Chains fire manually (shortcut/gesture/quick-command, no content match, no shell); userscript managers (Tampermonkey/Greasemonkey) match on URL and run sandboxed JS with no OS shell (they would need their own native-messaging host); Arc Boosts inject per-site CSS/JS, not regex-gated command chains. "None found", not proven — the web survey is not exhaustive. shell/host steps carry the same privileged-local-process trust model as any native-messaging host and are inert without zwire-host connected.

zwire-host doubles as a theme bus: a single shared file, ~/.zwire/global.toml (overridable via $ZWIRE_GLOBAL_DIR), holds one { scheme, ui{ light, scanlines, vignette, glow, anim } } record (8 named schemes — cyberpunk / midnight / matrix / ember / arctic / crimson / toxic / vapor), and whichever process the user re-themes in writes it. Because each app runs its own host process with a process-local pub/sub bus, a background file watcher bridges the gap: it polls the shared file (~700 ms) and republishes any scheme/ui delta onto the local bus topics scheme / ui, with echo-suppression so a process never re-publishes its own write — so a toggle in one app fans out live to every other running app; a peer::broadcast hop federates the same change cross-machine. Every write also drops plain-text projections (hud-scheme / hud-light) beside the TOML so a native reader needs no TOML parser. Two front-door adapters ride on top: a Tauri v2 plugin named zwire-theme (.plugin(zwire_host::tauri_theme::init()), two lines) that registers theme_get/theme_set and emits a global theme-changed event, and a transport-abstracted frontend shim zgui-core/webui/theme-sync.js (ZGui.themeSync) that speaks either Tauri invoke/listen or JUCE native-fn/backend-events and applies the snapshot onto ZGui.colorscheme + fx (inert no-op where no host is connected). Live consumers: the zwire HUD extension (background.js subs scheme+ui, writes local picks back), the zpwrchrome extension (persistent native port, applyScheme on push), the Chromium-fork native chrome (patch 0002-ui-colors-hud.patch reads the hud-scheme/hud-light projections via a FilePathWatcher and live-repaints window chrome), and the ztranslator GUI app (app/src-tauri/src/lib.rs registers the zwire-theme plugin; zwire-host { tag = "v0.3.5", features=["tauri"] }) — so one ~/.zwire/global.toml is the single source of truth wiring the browser (two extensions + native chrome) to a desktop app's colour scheme in real time. Basis: zwire/extensions/hud-internal/native/zwire-host/src/theme_watch.rs (700 ms poll → bus::publish("scheme"|"ui"), note_scheme/note_ui echo control); store.rs:26 (SCHEMES whitelist), store.rs:240 (theme_dir → ~/.zwire), store.rs:319 (cross-process read-modify-write lock on global.toml.lock), plus hud-scheme/hud-light projections; api.rs:183 theme_get / :193 theme_set_scheme / :204 theme_set_ui / :218 theme_watch; tauri_theme.rs (the zwire-theme plugin, theme-changed emit); zgui-core/webui/theme-sync.js (Tauri/JUCE transport, applyTheme onto ZGui.colorscheme/fx); zwire/extensions/hud-internal/background.js (sub scheme+ui, write-back); zwire/extensions/zpwrchrome/background.js (applyScheme); zwire/fork/patches/0002-ui-colors-hud.patch (FilePathWatcher on the projections); ztranslator/app/src-tauri/src/lib.rs. Caveat: "None found", not proven — OS-level light/dark follows a system setting, and design-token pipelines share palettes at build time, but a native local-host daemon that live-syncs one running colour scheme across a browser (extensions + native window chrome) and a Tauri desktop app via a shared file + per-process pub/sub bus + drop-in plugin has no prior art found; search not exhaustive. The shim is a generic drop-in (vendored into every zgui-core app's lib/), so any Tauri/JUCE zgui-core app can join by registering the plugin + loading the shim. Version drift exists across the pins (local crate 0.3.14, ztranslator v0.3.5, zpwrchrome-host on the crates.io 0.3 line resolved to 0.3.8, without the tauri feature). Inert wherever the host isn't connected.

zmax — a terminal TUI editor, not a browser or a Tauri/JUCE GUI app — joins the #169 ~/.zwire/global.toml theme bus as a first-class peer in both directions, without the zgui-core JS shim or the zwire-theme Tauri plugin those GUI consumers ride on (a terminal editor can host neither). Read side: a dedicated native notify watcher on ~/.zwire re-applies the matching theme the instant zwire's {scheme, ui.light} changes — no keypress or focus event — hopping onto the editor's main thread via job::dispatch_blocking, and maps the 8 bus schemes onto zmax's own ported zgui-<scheme> / zgui-<scheme>-light themes. Write side: committing a zgui-* theme in the editor (:theme, the picker, :theme-toggle) reverse-maps to (scheme, light) and rewrites just those two keys in global.toml (format-preserving via toml_edit, atomic temp+rename — zwire's other keys anim/glow/scanlines/vignette left byte-intact), which zwire's own watcher then fans out to the browser + native chrome + GUI apps. Echo between the two watchers is broken by writing only on a committed set (picker previews, which leave last_theme = Some, are excluded) and skipping any write whose values already match on disk. Behind one editor setting (sync-zwire-theme, default off). Basis: zmax/zmax-term/src/zwire.rs (theme_name:114 + theme_name_from_toml:121 read/map; scheme_from_theme:172 reverse-map; spawn_watcher:333 / run_watcher:346 the notify watcher → job::dispatch_blocking → apply:302; write_back_to:198 the toml_edit surgical edit, write_atomic:244); zmax/zmax-term/src/application.rs:582 (write-back hook at the single ConfigEvent::ThemeChanged choke, gated on last_theme.is_none() to exclude previews), :191 (watcher spawn at boot); zmax/zmax-view/src/editor.rs:564 (sync_zwire_theme setting); scheme whitelist zwire-host/src/store.rs:26 (SCHEMES). Caveat: extends #169's existing theme bus rather than inventing colour-scheme sync — file-based multi-app palette propagation is prior art (base16-shell, pywal, wpgtk), and #169 already wires the browser + Tauri/JUCE apps; the narrow increment here is a terminal modal editor joining that specific bus bidirectionally via a native watcher + format-preserving write-back that maps onto the editor's own ported themes (the GUI consumers' JS/Tauri adapters can't apply to a TUI). Default-off; only the 8 zgui-* schemes round-trip (non-app-shell editor themes are never pushed). Verified: 13 unit tests + an end-to-end pty run (:theme zgui-matrix → global.toml scheme=matrix, other keys preserved).

zwire compiles a full mastering chain into the Chromium audio service itself and applies it in OutputController::OnMoreData() — the per-stream output pull that every browser sound passes through before the OS device (HTMLMediaElement, MSE/YouTube, Web Audio, WebRTC alike), below the renderer's AudioRendererMixer (which streaming tabs bypass). The chain is per-stream, sample-rate-adaptive, and unity-by-default (bit-identical passthrough until a control engages it): preamp → parametric RBJ-biquad EQ cascade → gain → drive → stereo-linked compressor → feedback delay → reduced-Freeverb reverb (4 combs + 2 all-passes/ch) → M/S stereo width → equal-power pan/mono → brickwall limiter. It is live-reconfigurable with nothing open and no relaunch: the sandboxed audio service can't read the config file, so the unsandboxed browser process polls $STATE/audio-eq (25 ms) and pushes the spec over a new mojom AudioService::SetZwireEqConfig, which atomically swaps a process-global config every block; bin/zwire seeds it at launch (--zwire-audio-eq) so audio is shaped from the first block. A companion meter back-channel streams the REAL post-DSP output (Goertzel spectrum + peak/RMS + phase correlation + decimated stereo scope) via mojom ZwireMeters.Pull → $STATE/meters → the native host → the HUD Audio page — with no tabCapture (which mutes the source + drops audio on release), so closing the page never touches audio. Basis: zwire/fork/patches/0022-audio-eq-output.patch (services/audio/output_controller.cc OnMoreData() → ZwireAudioEq per-stream chain; ZwireMeterWrite/ZwireMeterSnapshotJson); 0024-audio-live-config.patch (mojom SetZwireEqConfig live push off a browser-process file poller + a ZwireMeters pool-sequence meter feed); zwire/extensions/hud-internal/pages/audio.js (dashboard buildSpec/parseSpec + charts); zwire/bin/zwire (launch seed). Caveat: "None found", not proven — OS-level system equalizers shape all audio but aren't browser-internal or tab-independent at the browser's own mix stage; per-tab Web-Audio EQ extensions exist but only over captured/routed streams (they miss MSE/WebRTC and mute the source); no browser was found applying a user-controllable mastering DSP chain at its audio-service output chokepoint with a post-DSP meter back-channel; search not exhaustive. Capability requires the native fork build (the MV3 extension layer can't reach the audio service); the DSP was verified in isolation and runtime-verified @150.0.7871.46, but prior-art absence is not exhaustive.

Beyond faithfully porting BOME (#94/#95), the engine extends it past MIDI in directions BOME has no equivalent for: ~25 incoming trigger sources (the captured matrix item was outgoing-only), live audio-feature extraction to MIDI (peak amplitude, adaptive-baseline onset, autocorrelation pitch → note number), a eurorack CV/gate bridge over a DC-coupled audio interface (read/write per-channel DC levels + gate thresholds), and a clock/timecode generation hub (24-PPQN MIDI clock slaved to Ableton Link, streaming MTC quarter-frame master, MMC). Basis: ztranslator-core/src/model.rs Incoming enum + src/engine/mod.rs. Caveat: audio/CV/gate are macOS-only; CV correctness depends on a genuinely DC-coupled interface.

LockFreeStreamSource starts playback from a disk-backed reader for instant audio, then atomically swaps in a RAM-backed reader mid-playback without the audio thread observing the switch (ring buffer on a background TimeSliceThread, SpinLock + generation counters instead of a CoreAudio-blocking CriticalSection), and models a synthetic EOF so toggling loop off plays the current iteration to its natural boundary. Basis: zdsp-core/include/zdsp/lock_free_stream_source.h (363 L). Caveat: RT-safety rests on review of the atomics, not a test; ported from the Audio-Haxor engine.

A dozen otherwise-unrelated desktop products are each built as the same engine shape: one Engine::invoke(cmd, json) → json command surface, compiled as rlib and staticlib and cdylib, fronted by a hand-written C ABI and a header-only C++ RAII wrapper and a mountable framework-free webview, and a Tauri v2 plugin — so identical behavior embeds in a Rust app, a C/C++ host (e.g. a JUCE DAW), and a webview. Basis: the identical pattern in zftp-core, zreq-core, zemail-core, zcite-core, zcontainer-core, zphoto-core, zpdf-core, ztranslator-core, ztunnel-core, zgo-core, zoffice-core, zdsp-core. Caveat: the individual apps are largely ports; the systemic, uniform reuse of one embeddable-engine contract across this many domains is the claimed novelty, not the apps.

A consistent, stack-wide stance of reimplementing normally-vendored primitives from scratch — pinned to published spec vectors — to keep cores pure-Rust, build-dependency-light, and offline: hand-rolled MD5/SHA/HMAC vs RFC/FIPS vectors (zreq-core/src/crypto.rs), gRPC .proto compiled at runtime via protox with no protoc (zreq-core/src/grpc.rs), a stored-ZIP writer with its own CRC-32 + font8x8 template OCR (zpdf-core/src/{convert,ocr}.rs), STUN/TURN NAT traversal with no third-party crate (strykelang), and byte-parity ports that run the upstream interpreter as an oracle (powerliners). Basis: the cited modules across the stack. Caveat: a recurring engineering philosophy, not a single artifact; the reimplementations are subsets, not always audited.