— 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 eighteen independent language frontends (strykelang/Perl 5, zshrs/zsh, awkrs/AWK, vimlrs/VimL, elisprs/Emacs Lisp, rubylang/Ruby, pythonrs/Python, phplang/PHP, node-js/JavaScript, rlang/R, go-rs/Go, javars/Java, kotlinrs/Kotlin, scalars/Scala, groovyrs/Groovy, tclrs/Tcl, texrs/TeX, and the original pipeline-UI language arb) each targeting the same fusevm bytecode. Every one ships a standalone binary, --lsp and --dap servers, shell completions, man pages, generated reference.html, --dump-tokens/--dump-ast/--disasm introspection, and the --tiers execution-tier report (#11n), and every one takes inline Rust FFI — texrs, the newest, was the last to close those two gaps. The novelty is the combination: solo author + from-scratch VM with a genuine machine-code JIT + 17 production 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; eighteen 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 (~235 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 JitConfig fields max_inline_recursion / max_trace_chain :359-361, both defaulting to 4 :377-378); 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 on-disk cache (on by default with the jit-disk-cache feature; FUSEVM_JIT_CACHE_DIR=off disables it) 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.

The disk cache of #4 is not namespaced per language, per binary, or per process: blobs are keyed only by chunk op-hash + tier tag ({op_hash:016x}.{sub:016x}.{tag}.fjit) in one shared directory, so every fusevm frontend reads and writes the same store. All eighteen frontends enable it, so the cache compounds — native code paid for once by any language, in any process, is streamed back by all of them, and the store keeps filling as the stack is used. The concrete consequence inside zmax: sourced Vimscript and Emacs Lisp — a .vimrc, an init.el, and the plugin files they :source / load / require — execute on the same JIT-enabled VM as the standalone CLI runtimes, so an editor plugin's hot loops persist their compiled machine code to ~/.cache/fusevm-jit on first run and skip Cranelift codegen on every later boot. Legacy plugin code gets tiered native execution with no plugin-side change and no per-editor cache. Basis: cache-dir resolution fusevm/src/jit.rs:3389-3403 ($FUSEVM_JIT_CACHE_DIR → $XDG_CACHE_HOME/fusevm-jit → ~/.cache/fusevm-jit); on by default with the feature, =off to disable (:3378-3386); un-namespaced blob name :3893; all three tiers persisted — try_load_or_build :4142, try_load_or_build_block :4162, try_load_or_build_trace :4187 with KIND_LINEAR/BLOCK/TRACE :3191-3193, MAGIC FJITNAT3 + SCHEMA_VERSION = 16 :3199-3219, 256 MiB default cap evicting oldest-first to 80% (:3940, eviction prune :4031). Eighteen frontends declare features = [… "jit-disk-cache" …] on fusevm (arb, awkrs, elisprs, go-rs, groovyrs, javars, kotlinrs, node-js, phplang, pythonrs, rlang, rubylang, scalars, strykelang, vimlrs, zshrs Cargo.toml; tclrs Cargo.toml:105). Editor path: zmax/zmax-term/src/commands/scripting/mod.rs load_init_scripts → vimlrs::fusevm_bridge::eval_file (:1092) → vimlrs/src/fusevm_bridge.rs:7089 (rkyv bytecode cache) + enable_tracing_jit :6106; elisp load/require → elisprs/src/host.rs:6336 intrinsic_load → run_top_forms (elisprs/src/lib.rs:113) → run_chunk (elisprs/src/host.rs:7013, enable_tracing_jit :6993). Caveat: persistent native/AOT caches exist (JVM AppCDS/JWarmup, .NET ReadyToRun, V8 code cache); the claimed novelty is a single un-namespaced one serving eighteen distinct language frontends and an editor's plugin runtimes, not caching per se, and the survey behind "first" is non-exhaustive. Cross-language reuse only lands where two frontends emit byte-identical op sequences; a chunk carrying frontend-registered extension helpers misses safely and recompiles (fusevm/src/jit.rs:3224-3230). The cache removes codegen only — parse/lower still runs each boot unless the frontend has its own bytecode cache (vimlrs does, ~/.cache/vimlrs/scripts.rkyv; elisp load does not, it calls run_top_forms directly). vimlrs suppresses the JIT in the tolerant per-statement fallback used when a config file fails to parse whole (fusevm_bridge.rs:6063), so those files get no cached native code. No cold-vs-warm plugin-load timing is recorded 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.26.0" 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.26.0" 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.

rlang is the fifteenth fusevm frontend: it lexes and parses R to an AST, lowers it to fusevm bytecode on an RHost vector heap, and runs it on the shared three-tier Cranelift JIT — with no bespoke VM or JIT of its own. GNU R's own "JIT" (compiler::enableJIT, default level 3 since R 3.4.0) compiles closures to R bytecode that a C interpreter loop then walks; rlang instead lowers for / while / repeat / if / && / || to native fusevm jumps with native integer loop counters, so the tracing JIT sees ordinary loops and emits machine code. R's value model is preserved: everything is a vector (no scalars), values carry names/dim/class attributes, every operator recycles and propagates NA, and copy-on-modify semantics hold for complex assignment targets (l$v[2] <- 9, names(x) <- v). Implemented: the standalone Rscript binary + REPL, the primitive library, S3 dispatch, the rkyv bytecode cache, an AOP call-intercept registry, an LSP server, a DAP adapter, and --dump-tokens / --dump-ast / --disasm introspection. Distilled, a single unified VM core yields a ten-part R platform: (1) the first R engine in Rust (memory-safe lexer / parser / compiler); (2) fusevm's slot-indexed, stack-based VM runtime; (3) its three-tier Cranelift JIT with native loop lowering; (4) AOT compilation two ways — --build warms the rkyv/bincode bytecode cache (~/.rlang/scripts.rkyv), and --aot links the emitted fusevm object against the rlang runtime staticlib into a standalone native .fvm executable with the R closures embedded in the chunk name table (aot.rs, aot_runtime.rs); (5) the AOP call-intercept telemetry registry; (6) fusevm's zero-cost inline-Rust FFI bridge exposed to R via .rust(code) (compile a self-contained Rust block to a cached cdylib) and R's own .Call(name, …) verb (invoke its exports, marshalling length-1 vectors to i64/f64/string and back), behind fusevm's ffi feature (ffi.rs, builtins.rs); (7) an interactive --disasm bytecode disassembler; (8) --dump-tokens lexical-stream tracing; (9) --dump-ast structural rendering; and (10) a wasm32-unknown-unknown build — the same crate on the bare fusevm interpreter (Cranelift/ffi/LSP/DAP target-gated off), R output routed through a capture buffer, exporting rlang_eval / rlang_alloc / rlang_free for a web-worker host (wasm.rs). Basis: rlang/src/{lexer,parser,compiler,host,builtins,ffi,cache,intercepts,lsp,dap,repl,aot,aot_runtime,wasm}.rs; Cargo.toml native fusevm = { version = "0.17.0", features = ["jit", "jit-disk-cache", "aot", "ffi"] } with the wasm target on the bare interpreter, and crate-type = ["rlib", "staticlib"] (the wasm cdylib emitted on demand via cargo rustc --crate-type cdylib --target wasm32-unknown-unknown); a differential parity harness (cargo run --bin parity, src/bin/parity.rs) diffs a 48-snippet corpus (tests/data/parity_corpus.R) live against the system R, and tests/parity.rs replays the frozen outputs in CI with no R installed; man/Rscript.1, completions/_Rscript, docs/ + generated reference.html. Caveat: R-to-native-code is not itself a first — Renjin compiles R to JVM machine code and FastR/TruffleR JIT-compiles R on GraalVM — so the defensible claim is the narrower combination: R lowered onto a shared multi-frontend bytecode VM with a Cranelift JIT, in Rust, with no JVM/GraalVM and no GNU R runtime linked. Early: arguments evaluate eagerly rather than as promises, so substitute() / quote() / NSE are unavailable; tryCatch and the condition system, data frames, factors, complex numbers, and apply over matrix margins are not implemented (BUGS.md); the DAP adapter is handshake + run-to-completion (stepping pending). "First" rests on a non-exhaustive prior-art sweep. MIT.

go-rs is the sixteenth fusevm frontend and a pure frontend: it lexes Go (including the language's automatic semicolon insertion), parses it, and lowers the AST straight to fusevm::Chunk bytecode — there is no bespoke interpreter loop, so execution and codegen are the shared three-tier Cranelift JIT. Go's + string-concatenation overload and string ordering dispatch through fusevm's strict numeric hook; goroutines / channels / select run on fusevm's own scheduler ops rather than a vendored Go runtime. Implemented: the go driver with run / build / vet / env / doc / version / help subcommands, go build AOT-linking a standalone native executable against the go-rs runtime (no go toolchain and no go-rs needed to run it), a natively-implemented (Rust host-builtin) standard library that grows package by package — an unimplemented import is a clear error, not a silent miss — plus an LSP server, a DAP debug server, and --dump-tokens / --dump-ast / --disasm introspection. Basis: go-rs/src/compiler.rs (3,930 L), host.rs (2,138 L), parser.rs (2,091 L), lsp.rs (624 L), lexer.rs (610 L), dap.rs (572 L), aot_native.rs (120 L), plus pkg.rs / stdlib_vendor.rs / rust_ffi.rs; Cargo.toml fusevm = { version = "0.15.0", features = ["jit", "jit-disk-cache", "aot", "ffi"] }. Caveat: the gc toolchain already compiles Go to native code, and TinyGo already lowers Go through LLVM — so the defensible "first" is the narrower combination: Go lowered onto a shared multi-frontend bytecode + Cranelift JIT + native AOT, authored in Rust, not "first compiled Go" outright. It is an executor swap, not a gc replacement: the standard library is reimplemented natively package by package rather than vendored, and concurrency programs need the scheduler, so goroutine/channel/select code runs under go run rather than go build. "First" rests on a non-exhaustive prior-art sweep. MIT.

tclrs is the seventeenth fusevm frontend and a pure frontend: it parses Tcl — resolving every substitution the grammar permits at parse time — and lowers each command straight to fusevm::Chunk bytecode. There is no interpreter loop and no code generator in the crate; execution belongs to the shared VM. Two properties of Tcl's grammar are what make ahead-of-time lowering pay: braces suppress substitution, so a braced body (an if or while body, a braced expr expression) is fully known at parse time and compiles once instead of being re-parsed per evaluation — words carry a braced flag for exactly that decision — and rule 11 rules out rescanning substituted values, so each character is processed once. Tcl's value model needs no object heap on top of fusevm's: strings, integers and floats map onto Value directly, and a value keeps its numeric representation until something demands its string form. Implemented: the parser (all twelve syntax rules of Tcl(n)), the compiler with statically tracked stack depth (so break/continue unwind by a compile-time-known pop count rather than a runtime unwinder), set / puts (-nonewline) / expr / incr / if-elseif-else / while / break / continue plus command substitution of any of them, and the whole expr(n) operator set at expr(n) precedence compiled straight from a braced word with no runtime parse. Since then the frontend has grown the rest of the language surface — proc (parameters and locals as frame slots, defaults and a trailing args resolved at the call site), for / foreach / switch, catch / error / return, the string / array / dict ensembles, the list commands, and coroutines (coroutine / yield / yieldto, a coroutine being a second VM over the same chunk) — and the toolchain around it: a tclrs binary with a reedline REPL, --lsp and --dap servers, _tclrs completion, man/man1/tclrs.1 + tclrsall.1, a generated reference.html, inline rust {} FFI, and --dump-tokens / --dump-ast / --disasm. Tcl semantics ride two hooks: a numeric hook for operands the VM cannot compute on natively (an operand that parses as a number is one; comparisons fall back to string order when it does not) and frontend extension ops for the operators whose Tcl meaning differs from the VM's generic one (/ and % floored toward negative infinity, integral **, and a normalize op for Tcl's boolean and double formatting). Since that phase it has also grown {*} argument expansion, the expr(n) math functions, bignums, namespaces, channels and encoding, clock, regexp, format, and an optional --features tk build whose --tk session runs the interpreter on the process main thread. Basis: tclrs/src/parser.rs (1134 L), compiler.rs (3359 L), expr.rs (996 L), runtime.rs (4894 L), 44 modules in all; Cargo.toml fusevm = "0.26.0" with jit / jit-disk-cache / aot / ffi; tclsh 9.0.4 is the specification (pinned by tests/version_pin.rs) and the suites diff against it directly — 55 test binaries in all (tests/*.rs), among them per-area differential suites for words, execution, procedures, lists, strings, arrays, coroutines, namespaces, channels, encodings, clock, regexp, format, bignums and {*} expansion, 14 rule-by-rule parser tests (tests/dodekalogue.rs), and a replayed corpus of the divergences a differential fuzzer found (tests/parity_fuzz_findings.rs, 50 tests), so no expected output in the repository is hand-written. Beyond its own suites the crate runs Tcl's own test suite against itself: 29,335 of 48,201 attempted cases pass — 60.9% (conformance/REPORT.md, regenerated by conformance/run.sh, which lifts every case out of every tests/*.test file and counts a pass only when tclsh and tclrs agree on exit code, result string and stdout, byte for byte). Caveat: the refusals are named rather than approximated and README.md §0x05 is the list — among them a non-literal ensemble subcommand or body word (while $cond $body), a computed namespace eval name and namespace path / unknown / upvar, info frame / errorstack / cmdcount, clock scan without -format, regexp -about, format %a, open |command, fconfigure -blocking 0, the ISO-2022 escape-sequence encodings, and --aot for a script using catch or a coroutine. Tcl has compiled to bytecode on its own engine since 8.0, so the defensible "first" is the narrower combination: Tcl lowered onto a shared multi-frontend bytecode VM, authored in Rust, with no Tcl runtime linked — not "first compiled Tcl" outright. "First" rests on a non-exhaustive prior-art sweep. MIT.

A rust { pub extern "C" fn … } block in a .tcl file compiles to a cached cdylib whose exports become ordinary Tcl commands. Basis: tclrs/src/rust_ffi.rs supplies the Tcl-flavored fusevm::RustSugar — the block is rewritten to __rust_compile <base64> <line> before parsing, padded to preserve line numbers — and Compiler::cmd_rust_compile registers it while lowering it, because this frontend resolves dispatch at compile time; ext::FFI_CALL is emitted for a name fusevm::ffi reports as exported. Test-verified: tclrs/tests/rust_ffi.rs — 7 tests pass (i64 and *const c_char signatures, a result used inside expr, a Tcl proc shadowing an export, a block that fails rustc failing the script with the line it was written on, arity refusal). Caveat: the concept has deep prior art in Tcl — critcl has embedded C in Tcl scripts, cached by checksum and dynamically linked, for two decades. The novel legs are the language (Rust), the shared fusevm::ffi substrate across eighteen frontends, and compile-time registration into a statically resolved dispatch; signatures are limited to fusevm's marshalling set (≤4 i64 → i64, ≤3 f64 → f64, *const c_char → i64 or *const c_char).

<binary> --tiers <script> runs the program, then reports, per compiled chunk, whether the block tier holds native code for it, which loop headers the tracing tier compiled, which it blacklisted, and — when a tier refused — a histogram of the JIT-ineligible ops that caused the refusal. Shipped in all eighteen frontends. The point is that the report does not guess: it asks fusevm's own predicates, the same ones the compiler consults before doing the work, so "the JIT is enabled" and "the JIT compiled this" stop being the same sentence. Basis: <repo>/src/tiers.rs in seventeen frontends and strykelang/strykelang/tiers.rs in stryke — all eighteen tracked, 6,399 lines total; each queries fusevm::JitCompiler::is_block_eligible (fusevm/src/jit.rs:8059), block_jit_is_compiled (:8069), find_jit_region (:8078), is_trace_eligible (:8231), trace_is_compiled (:8238), and trace_is_blacklisted (:8321) after the run. Report { chunks: Vec<ChunkTiers> } carries one section per chunk, because a hot loop usually lives in a function body and reporting the main chunk alone answers the wrong question; the == name == header is suppressed when a program compiled to exactly one chunk. What differs per frontend is only where the chunks come from — Program main plus functions for the dynamic frontends, BEGIN/rule/END for awkrs, script plus functions_compiled for zshrs, closure bodies walked off the host arena for elisprs, one chunk for the JVM frontends and go-rs. Caveat: not a first in the sense of "nobody reports JIT state" — every serious JIT has some introspection (-XX:+PrintCompilation, --jit-debug, perf annotations). The claim is narrower: one report format, one set of predicates, one implementation shape, answered identically by eighteen different languages, because the tier decisions are the shared engine's rather than each language's. Whether a given program reaches native code is a property of that program's loop shape, not of the frontend — several frontends lower loop bodies through CallBuiltin/Extended, which the tracer declines, and the report is what makes that visible instead of inferred.

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.26.0" 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) → 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 them, restores one by atomic swap, and structurally diffs two snapshots per-record (added / removed / changed) — git-like state archaeology for a shell environment. Basis: daemon/snapshot.rs — op_snapshot_save:81, op_snapshot_list:139, op_snapshot_load:178, op_snapshot_diff:323 (~/.zshrs/snapshots/<tag>.rkyv), with daemon/auth.rs:175-176 scoping exactly those four ops to snapshot.read / snapshot.write; DAEMON_AS_SERVICE.md. Caveat: there is no bisect op — bisecting to the first diverging record is described in the module doc header but is not implemented; only save/list/load/diff ship. 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, role_to_ansi, autosuggest_from_history — reverse prefix-then-substring history search matching fish's suggestion order, validate_autosuggestion, plus fish abbreviations, kill ring, validate_command); in-module tests (e.g. autosuggest_from_history("git s", …)); 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: the module is implemented and test-verified but not yet wired into the live ZLE keystroke path (only re-exported — no call sites in the input loop found); "history search" today is the suggestion-search engine, not a ported fish Ctrl-R pager; "first" rests on non-exhaustive prior-art absence (no other shell found shipping fish's trio natively in-binary).

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"; carried into zshrs as #40f, where the heap-Arc key had to be replaced. 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 reflection table is include!()'d from OUT_DIR at builtins.rs:53, with the "reflection"-tagged names 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 (frontend/vendor/zpwr-clip-engine), registers the six FFI commands clip_seq_{pattern,transport,play,step,poll_events,export_midi} in traderview/src-tauri/src/lib.rs:492-497 (state at :294), and mounts the grid in frontend/js/views/sequencer.js; ztranslator imports ./vendor/zpwr-clip-engine/webui/clip/clip-seq.js and calls initClipSeq(...) from crates/ztranslator-core/frontend/ztranslator_view.js:1235-1258, driving the real C++ engine under Tauri and the non-audio JS step backend in a plain browser. What is still design intent is those timelines carrying domain payloads (trades, translation events) rather than notes.

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) = 21; BLOCKS.md PHY badge. 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_*, engine/CMakeLists.txt:18,21 (zpwr_clip_engine SHARED + zpwr_clip_engine_static STATIC), webui/clip/clip-seq.js, 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 grid/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; 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 webui/*.js module each) — 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/Helix-modal editor 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, frontend/main.js zgui widgets → PTY (with frontend/panels.js and frontend/tmux-config.js alongside it). 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 in the monorepo; 31 of the 32 READMEs carry the [stryke-package] badge (stryke-app does not). Caveat: "first for a Perl5-like language" is a framing claim; tiers vary in maturity; breadth, not any single deep integration, is the novelty. stryke-demo/README.md:17,65 covers only the 14 packages it ships live demos for (a single s install pulls those 14) — it is not evidence for the full 32.

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,13-17 self-assesses 96.6% weighted Zotero coverage (82 full / 6 partial / 0 missing / 4 out-of-scope, over 88 features). Caveat: "in development"; a reimplementation of Zotero — the novelty is the embeddable-engine packaging.

zmax embeds twelve scripting interpreters — Emacs Lisp, Vimscript, AWK, arb, zsh, stryke, Ruby, PHP, Python, JavaScript (Node), R, and Tcl — 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:95 ("the only IDE to embed 12 scripting languages with zero external dependencies and no FFI between them") and README.md:100 (the twelve :-commands); zmax/zmax-term/src/commands/scripting/pipeline.rs:60-62, whose LANGUAGES table is the machine-readable list of the same twelve; book/src/scripting.md (SPC a r unified REPL); each is a pure-Rust crate lowering onto shared fusevm bytecode. Chained as pipeline stages, they are #209. Caveat: overlaps #1 (the editor- 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.

zmax is a Helix fork — tree-sitter language breadth, rainbow brackets, indent queries, and the core modal model are Helix base and not claimed. The entries below (per CHANGELOG + source) are zmax's own additions on top of Helix.

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 Helix-based modal editor is the novel part (Helix has none).

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 Helix fork. 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 editor. 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 Helix fork (Helix has none) 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, in a Helix fork, 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 (Helix has snippets, no managing TUI).

A labelled Spacemacs SPC command tree ported onto the Helix 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 a Helix 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 (Helix is TOML-by-hand only).

zmax ships a Cursor-style AI assistant compiled into the editor 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 editor 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 (Helix-fork) 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 for Alpaca/IBKR/Schwab/Tastytrade/Tradier plus Webull(RO), with reconnecting WS fill-pumps for the five trading brokers, 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.rs (read-only, no pump), 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.

### zgui-core — original components in the shared library

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.

### Shared libraries & infrastructure

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.

### zwire — a Chromium browser with built-in tmux-style multiplexing

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 — across two surfaces: an in-page 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. Basis: the HUD's former standalone ztmux.js was removed (commit cc46c47065) and the in-page surface now runs on the same shared engine as #170 — lib/zgui-core/webui/tmux.js (1,474 L) — driven by two thin HUD adapters, zwire/extensions/hud-internal/ztmux-pane.js (252 L, isPrefix() Ctrl-b/⌥-b, pane forwarding) and 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. 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 manifest.json:292 — it superseded the removed zstatus.js in commit cc46c47065): an adapter that feeds the shared ZGui.powerline component (which owns the chevron rendering) from chrome.storage — sysStats() reads zb_sys, tmuxStatus() reads zb_tmux, and ZGui.powerline.arm() lights the prefix lamp off zb_tmux.armed; 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 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:6 (capability list), fsops.rs:116 (fs_walk recursive crawl) + api.rs:107 (walk) + api.rs:44 (exec); zmax/zmax-term/src/commands/host.rs:1 (client bridge, auto-spawn serve); zpwrchrome/zpwrchrome-host/Cargo.toml:52 (zwire-host = { version = "0.3", default-features = false } — a crates.io registry dep, resolved to 0.3.8 in the lockfile). 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's Output Triggers take the #168 typed step-chain and fire it automatically when a user regex matches page text as it renders/streams — the browser-native analog of a terminal emulator's output triggers (iTerm2, zterminal: regex-on-output → run command), moved off scrollback onto live web-page text. A content-script MutationObserver scans rendered lines (throttled, line-capped, minified-blob-skipped, and excluding zwire's own HUD/toast DOM to avoid feedback loops); on a match it runs the identical typed chain (url / action / scheme / js / shell / host) through the shared window.ZWIRE_CMD_EXEC.runCustom executor, with the matched line bound to {q} in every step, an optional URL-filter regex scoping which pages arm a trigger, a per-trigger cooldown (default 1500 ms) against process storms, and an optional once-per-page-load mode. Basis: zwire/extensions/hud-internal/ztriggers.js (the content-script engine — compileOne regex + urlRe URL filter + cooldownMs/firedOnce storm control, fire() → window.ZWIRE_CMD_EXEC.runCustom({steps},line)); pages/triggers.js (full CRUD over chrome.storage.local 'zb_triggers'); pages/step-wizard.js (the per-step typed wizard shared verbatim with #168's commands.js); zpalette.js (ZWIRE_CMD_EXEC executor). Caveat: the increment over #168 is only the automatic firing — the step-chain, wizard, and executor are #168's, shared not re-invented. Regex-on-output triggers are prior art in terminals; the first-ness is browser-native (Vivaldi Command Chains fire manually with no content match and no shell, userscript managers match URLs and run sandboxed JS with no OS shell, Arc Boosts inject per-site CSS/JS rather than regex-gated OS-reaching chains). "None found", not proven; search not exhaustive. shell/host steps carry #168's privileged-local-process trust model and are inert without the native 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.

Stock git has no interactive console: every git <verb> is a fresh process, and the known "git shell" tools — thoughtbot's gitsh and rtomayko's git-sh — are wrappers that read a line and shell out to external stock git (fork/exec of the real git), so the REPL lives beside git, never inside it. zvcs ships the console inside the git binary itself: git zrepl reads each line and dispatches it through the same in-process dispatch::run the CLI uses — no fork/exec, no subprocess — so a REPL line and a shell git invocation hit identical code. Because it fronts zvcs's one dispatch table, the console drives both git-compat porcelain and the coordination superset stock git cannot have in one session (zjobs, zjob 3, zdaemon status, zsync, zclaim, … alongside status/log/diff). On a terminal it opens with a live-stats banner (logo + verb/repo counts pulled at render time) and edits with reedline: persistent history (~/.zvcs/repl_history), emacs or vi keys per zvcs.replvimode, and Tab completion of the command word against every dispatchable verb — both dispatch tables merged (dispatch::SUPERSET_VERBS + dispatch::PORCELAIN_VERBS, the same source of truth git zverbs lists) via a custom reedline::Completer and a ColumnarMenu bound to Tab/Shift+Tab on whichever insert keymap is active; piped/non-tty stdin degrades to a raw line reader (no banner, no completion) so echo 'zrepos' | git zrepl stays scriptable. Basis: zvcs/src/extensions/src/superset/repl.rs (the reedline console, ZreplCompleter over dispatch::SUPERSET_VERBS + dispatch::PORCELAIN_VERBS, run_one → crate::dispatch::run with no subprocess), superset/banner.rs (the width-correct live-stats banner), dispatch.rs (the single table both the CLI and the REPL route through); the shadow binary is [[bin]] name = "git" in src/extensions/Cargo.toml. Test-verified: src/extensions/tests/repl.rs::zrepl_runs_piped_commands_then_quits drives the piped path end to end. Caveat: an interactive git shell is not itself novel — gitsh and git-sh predate this; the candidate-first is the embedding: the REPL is part of a from-scratch git reimplementation and dispatches natively over both porcelain and a coordination superset in-process, rather than wrapping an external git. "None found," not proven; prior-art sweep non-exhaustive. A zvcs addition (gitoxide engine vendored). MIT.

Git's extensibility is a fixed set of lifecycle hooks (pre-commit, post-merge, … under .git/hooks) that fire only at git's chosen points and only for the operations git chose to hook; there is no way to wrap an arbitrary subcommand — git status, git push, git log — with before/after/around advice, and no git tool offers aspect-oriented interception of its own dispatch. zvcs adds it: git zintercept before|after|around <pattern> -- <cmd> registers AOP advice against a git-subcommand pattern (commit, commit *, */all), and because the one binary is the sole dispatcher (dispatch::run), every matching invocation runs the advice around the command. A before hook runs a shell command before the command; an after hook runs after it with the command's exit status and wall-clock in INTERCEPT_STATUS/INTERCEPT_MS/INTERCEPT_US; an around hook replaces it and runs "$INTERCEPT_CMD" to proceed with the original. The AdviceKind (before/after/around) + Intercept + intercept_matches (exact / glob / all) engine is ported from zshrs's own AOP intercepts and adapted to zvcs's per-process model: the registry persists to $ZVCS_HOME/intercepts.tsv and loads at dispatch (a single stat gates the hot path when empty), advice is a shell command carrying INTERCEPT_NAME/INTERCEPT_ARGS/INTERCEPT_CMD, and a ZVCS_INTERCEPTED env guard stops the wrapped command from re-intercepting itself. Basis: zvcs/src/extensions/src/superset/intercepts.rs (the ported AdviceKind/Intercept/intercept_matches, maybe_intercept orchestrating before→around/after, the TSV registry, the zintercept verb), the interception hook at the top of src/extensions/src/dispatch.rs; ported from zshrs/src/extensions/intercepts.rs. Test-verified: superset::intercepts::tests port zshrs's matcher tests (exact / glob / single-char / all) and cover the registry round-trip; end-to-end, git zintercept before version -- echo … prints the hook before git version runs. Caveat: AOP advice is not novel in itself — zshrs (this project) already ships before/after/around intercepts for shell commands, and function-wrapper hooks exist in zsh's addwrapper; the candidate-first is applying it to a VCS — before/after/around advice on any git subcommand, built into a git-shadowing binary, which git's fixed lifecycle hooks structurally cannot do. The interception companion to the zvcs coordination superset (#173). "None found," not proven; prior-art sweep non-exhaustive. A zvcs addition (gitoxide engine vendored; AOP engine ported from zshrs). MIT.

Managing many git repos is normally shell glue — for d in */; do (cd $d; git …); done — with no shared index, no live view, and one fork/exec of git per repo. zvcs makes the fleet first-class: a machine-wide index of every git repo (zreindex/zrepos), one selection grammar every fleet verb shares (Selector / [selectors]: a path pattern, --dirty/--ahead/--behind, --claimed/--session, ANDed), and one bounded worker pool (parallel_map) over which a family of verbs run native gix reads — no fork — across the whole set: queries (zheads/zdirty/zsize/zcommits/zpristine), analytics (zgrep/zahead/zbehind/zunpushed/zunpulled/zauthors/zhot/zconflicts), and parallel mutations through the fair per-repo lane (zfetch/zgc/zreset/zabort/zcommitall/zpushall). On top sit two observability instruments the shadow-binary design uniquely enables: git ztop — a full-screen, htop-style monitor of the entire fleet, every repo with a churn bar / HEAD / state, sorted so repos changing right now rise to the top, read from a daemon-maintained status cache each frame (no live walk, so it scales to thousands), rendering the 31 htoprs colorschemes with a live picker + palette editor, F1 help, sort-by-column, and / search; and git zcommands — a live feed of every git command run across the machine, which is only possible because the one binary is the sole git: each invocation logs time, pid←ppid (which agent ran it), cwd, and argv to its own log, gated by a single stat when off. Basis: zvcs/src/extensions/src/superset/query.rs (parallel_map + the fleet-query verbs), select.rs (Selector/SELECTOR_VERBS, test-guarded against drift), analytics.rs, pmutate.rs, ztop.rs (the ratatui monitor + status-cache read + ported htoprs colorschemes), statusd.rs (the producer/consumer status-cache maintainer), zcommands.rs (the fleet command log) + the log_invocation hook in dispatch.rs. Test-verified: superset::query/analytics/pmutate integration tests fan verbs across fixture repo sets; ztop/zcommands unit tests cover churn sort, theme round-trip, filter, and the command-log parse/backlog; selectors tests guard the grammar. Caveat: neither a repo-fleet manager (myrepos/mr, gita, ghq) nor a TUI process monitor is new; the candidate-first is the integration — a shadow git binary whose own dispatch is the fleet's sole entry point, giving fork-free parallel operations over a shared index, a live churn-sorted monitor off a daemon status cache, and per-command ppid attribution that only the sole-git design makes possible. The observability/parallel companion to the coordination superset (#173) and its interception layer (#181). "None found," not proven; prior-art sweep non-exhaustive. A zvcs addition (gitoxide engine vendored). MIT.

rkyv archives are not self-describing — the format stores layout and relative pointer offsets, no field names and no type tags — so there has never been a sqlitebrowser-equivalent for them: with no schema in the file, a generic reader has nothing to bind columns to, and inspecting a cache shard means writing a throwaway Rust program that links the producer's own types. zdbview closes that for the archives this stack actually produces, and goes past inspection to editing. It carries faithful copies of the producer's archive types, detects each by a magic word (or, for the header-less formats, a validation-gated try-decode attempted last so an unrelated archive falls through instead of mis-matching), validates with rkyv::check_archived_root — so a version/feature drift fails validation instead of silently decoding garbage — and renders real (key, value) records with per-entry scalar fields and a hex/text/disasm value pane. Eight formats are recognized, every script/heap cache the fusevm-hosted languages write: ZRSC (zshrs script) and ZRAL (zshrs autoload); STRY (strykelang, both the native-v4 six-field entry and the compat five-field layout under one magic); AWKR (awkrs); VIML (vimlrs); ELSP (elisprs heap image); and the two header-less caches recognized by try-decode — pythonrs bytecode (source-path keyed) and the shared rubylang/arb layout (u64 content-hash keyed). Recognized archives get full CRUD: create a record (a), update its value (e, text or 0x<hex>), rename its key (r, map-keyed formats), delete it (d). Every edit deserializes the shard, mutates it, and re-serializes it, then writes the file back atomically (temp + rename); the re-serialization is byte-identical to what the producing host writes — round-tripped against all six real cache formats — so the host reads the edited shard with no rebuild. Edits target a record's stable identity (map key, or the u64 hash for the header-less formats), so an update or delete touches exactly one entry even when many share a display key (pythonrs stores 177 records under 33 distinct <string>/<stdin> sources). Anything unrecognized degrades to a structural view rather than an error: printable-string runs with byte offsets, plus an xxd-style hex/ascii dump. The same binary opens SQLite databases with full generic CRUD — tables with row counts, paginated rows, in-place cell edit, insert-with-defaults, rowid delete, arbitrary SQL, a schema view (CREATE statements), and whole-table SQL-backed search across every column (not just the loaded page) — and picks the backend by header magic, not filename (SQLite format 3\0 is authoritative; a .db whose bytes aren't a SQLite header is opened as an archive), with extension used only for files too short to carry a header. Cross-cutting: a full-screen detail view with a scrollable value pane and an auto/hex/text/disasm render toggle, OSC-52 clipboard copy that works over SSH, non-interactive --export json|csv plus an interactive export key, and an MRU picker off $XDG_CACHE_HOME/zdbview/recent. An optional disasm build feature decodes a chunk_blob value as a bincode-encoded fusevm::Chunk using the real fusevm types — no vendored copy of the 267-variant Op enum, so no silent-misdecode risk; because bincode is version-sensitive it is correct only when the linked fusevm matches the version that wrote the cache and otherwise fails loudly and falls back to hex (off by default so the crate stays self-contained). Basis: zdbview/src/formats.rs (per-format magics + the copied ScriptShard/StrykeShard/AutoloadShard/ElispShard/PyShard/HashShard types pinned to rkyv 0.7 + archive_le + size_32, try_decode → check_archived_root, and the edit_shard deserialize→mutate→reserialize core behind add_record/set_value/rename_record/delete_record), src/app.rs (CRUD wired into the Records view with atomic write-back + reload, detail/schema/help screens, value-render toggle, whole-table search), src/sqlite.rs (find_row/rowid_ordinal whole-table search, schema, rowid-addressed CRUD), src/disasm.rs (feature-gated fusevm disassembly), src/export.rs, src/clipboard.rs, src/rkyv_inspect.rs, src/store.rs, src/mru.rs; ratatui 0.30 + rusqlite 0.40 (bundled) + rkyv 0.7, fusevm optional. Test-verified: cargo test → 20 passing — formats::tests::full_crud_roundtrip_on_map_format runs Create→Update→Rename→Delete and re-decodes at each step, python_delete_removes_exactly_one_of_duplicate_sources proves stable-identity deletes don't cascade across shared display keys, delete_record_removes_and_reserializes/script_shard_roundtrips_through_try_decode/hash_shard_roundtrips cover the archive round-trips, tests/backend.rs covers sqlite_full_crud_roundtrip, rkyv_structural_strings_and_hex, both detection paths and MRU dedup/order, plus search index math (find_next/find_bytes), export escaping, and base64 vectors; byte-identical re-serialization was additionally checked against every real on-disk cache via a harness. Caveat: a database TUI is a known category (sqlitebrowser, litecli, harlequin) and the SQLite half claims nothing new; the candidate-first is the rkyv half — GitHub repo search (rkyv viewer|inspector|tui|dump|browser), gh search code (ratatui rkyv), a crates.io sweep and web searches surfaced only the rkyv library and its docs, no archive viewer, and none with write-back. "None found," not proven; private and non-rkyv-named tools are outside what those indexes cover. Scope is honest: typed decode + CRUD covers the eight registered formats, not arbitrary archives (an unknown type still needs its Rust definition added to the registry); rename is offered only for the map-keyed formats; and disassembly is correct only when the linked fusevm version matches the cache's. Companion to the zshrs rkyv cache layer, whose shards it exists to inspect and edit. MIT.

Git's automation is pull-shaped: hooks fire only when you run a git command, so nothing happens between invocations. zvcs's daemon reacts to the machine instead. git ztrigger <DIR> <cmd> watches any directory recursively — it does not have to be a repository — and runs its command the instant a file under it changes, with a leading-edge throttle (default 500ms) so one save fires once rather than once per filesystem event, plus live views onto the fires (ztrigger tail streams them, ztrigger top is an in-place HUD of per-trigger counts and rate). git zon is the semantic half: it subscribes to typed events off the live feed — commit, stage, status, reconcile, optionally filtered by repo — and runs a command with ZVCS_EVENT/ZVCS_REPO/ZVCS_DETAIL/ZVCS_SHA in the environment, so a rule reads "when any repo commits, do X" rather than "when these bytes change". Both persist in the ledger (triggers / subscriptions tables), so they survive daemon restarts and are visible to every session. Basis: zvcs/src/extensions/src/superset/trigger.rs (the ztrigger/zwatch verbs, throttle, ~/.zvcs/fires.log tail/top), superset/zon.rs (subscription registry + typed dispatch), superset/watch.rs (the notify-driven daemon reactor that fires all three reaction kinds with no debounce). Test-verified: src/extensions/tests/trigger.rs::ztrigger_arms_dir_and_fires and ::zwatch_indexes_without_a_command drive the real daemon. Caveat: file watchers (entr, watchexec, fswatch) and event buses are old; the candidate-first is putting both inside the VCS — one binary that is git, watching non-repo directories and its own semantic feed, with the subscriptions stored in the same ledger the fleet verbs read. A command that itself commits can re-trigger its own subscription (documented; scope with --kind/--repo). "None found," not proven; sweep non-exhaustive. A zvcs addition. MIT.

A git hook is a file installed in every repo's .git/hooks; there is no way to say "for every repo on this machine, on commit, run X", which is why hook managers (husky, pre-commit, lefthook) exist to copy files into repos. zvcs inverts it: because every repo is in the daemon's index, the daemon watches them all and fires the hook named by [zvcs] hook in the repo's merged config — so one line in ~/.gitconfig applies to every watched repo and any repo may override it in its own .git/config, with nothing installed anywhere. The hook is not a bare notification: it runs under sh -c with the repo as cwd and a typed event context — ZVCS_EVENT classified from the reflog (commit, checkout, merge, pull, rebase, reset, clone, … falling back to ref-change), plus ZVCS_REPO, ZVCS_GIT_DIR, ZVCS_OLD_SHA, ZVCS_NEW_SHA, ZVCS_REF — which is enough to write cross-repo reactive rules ("on commit in this repo, do X in repo Y"). A failing hook is recorded in the ledger and surfaced on the next git command, since a daemon-fired hook has no exit code to return. Basis: zvcs/src/extensions/src/superset/hooks.rs (the merged-config hook lookup, reflog event typing, env contract, ledger failure record), superset/watch.rs (per-repo ref-tree watches). Test-verified: tests/hooks.rs::hook_fires_on_ref_change_in_watched_repo, tests/hook_event.rs::hook_receives_typed_commit_event, tests/watch_rescan.rs::a_repo_indexed_after_startup_is_picked_up_and_its_hook_fires. Caveat: hooks and hook managers are prior art; the candidate-first is a hook system whose trigger is the filesystem, whose declaration is git config, and whose scope is every indexed repo at once — none of which git's per-repo .git/hooks model can express. Local-events only: it sees ref moves on this machine, not remote activity. "None found," not proven; sweep non-exhaustive. A zvcs addition. MIT.

Protecting a workflow in git means writing hook scripts per repo (and hoping nobody --no-verifys), or enforcing it server-side after the fact. zvcs adds a policy layer at the one place every command must pass — its own dispatcher. git zguard deny 'push*--force*' refuses a force-push before it runs; git zguard warn 'rm*-rf*' allows it with a warning; and rules can carry a predicate evaluated against the live repository — --when detached (no commits on a detached HEAD), --when unsigned (require signed commits), --when protected (no push while on main/master). Rules are (action, pattern, predicate, message) tuples persisted to $ZVCS_HOME/guards.tsv, machine-wide rather than per-repo, with zguard list | rm | clear | test <cmd…> for management and a dry test that answers "would this be refused" without running anything. The hot path costs a single stat when no rule is set. Basis: zvcs/src/extensions/src/superset/guard.rs (rule model, glob matcher, the detached/unsigned/protected predicates, TSV registry, zguard/zpolicy verbs), the pre-dispatch check in src/extensions/src/dispatch.rs. Caveat: the veto evolution of #181's around-advice, and pattern-based command policy exists in other domains (sudoers, command_not_found guards, CI required-checks); the candidate-first is a VCS binary carrying its own declarative refuse/warn policy that applies to every invocation of itself, including the ones a .git/hooks script never sees (git log, git rm, git checkout). Advisory only against a user who invokes a different git binary. "None found," not proven; sweep non-exhaustive. A zvcs addition. MIT.

git status describes one repository at one instant. zdashboard is a full-screen, continuously refreshed console for the whole machine: a fleet tile (every indexed repo, most recently active first, read from the daemon status cache with the on-screen rows' HEAD state live-refreshed so nothing displayed is stale), a processes tile (each responsible process, its commit tally, live/dead state, last-commit age), an events feed (commits / stages / status changes / reconciles), and a commands feed (every git command run anywhere on the machine, attributed to the agent that ran it), with an aggregate header row. It is a real TUI, not a status dump: one tile is focused and its selected row is the cursor; Tab cycles tiles, ↑/↓/j/k/g/G move within one, the mouse moves the cursor under the pointer, the wheel steps it, right-click opens a per-row detail popup, feeds stay pinned to the newest row until you scroll up, and panes are resizable by dragging the divider (or H/L/J/K, = to reset) with per-pane minimums. It shares ztop's 31-scheme theme system, palette editor, and F1 help. Non-interactive callers keep an instant text summary (--once / --json / a non-tty stdout). Basis: zvcs/src/extensions/src/superset/dashboard.rs (the four tiles, cursor/mouse model ported from iftoprs, draggable dividers ported from zmax, theme integration, --once/--json paths), fed by superset/statusd.rs, zppid.rs, zevents.rs, zcommands.rs. Test-verified: tests/profiling.rs::profiling_and_dashboard_reflect_state; tests/json_output.rs::read_verbs_emit_valid_json covers the machine-readable path. Caveat: dashboards and TUIs are not novel, and this shares its substrate with #182; the candidate-first is the composition inside a VCS — repo state, process attribution, semantic events, and command history are four different observability domains, and only a binary that is simultaneously the fleet's git, its daemon, and its logger can show all four live at once. "None found," not proven; sweep non-exhaustive. A zvcs addition. MIT.

When N automated agents drive git concurrently, the obvious identity — getppid() — is useless: an agent spawns a fresh zsh -c … per command, so every commit reports a different parent and the data degenerates into a flood of one-commit rows. zvcs walks the parent chain instead, skipping transient wrapper shells (a shell invoked with -c, which runs one command and exits) and stopping at the first durable process — a real program (agent, editor, daemon) or an interactive login shell. That pid is stable across every commit one agent makes, so N concurrent agents map to exactly N rows, each carrying that process's command name and cwd so the number is legible. Attribution happens at command time: note_commit is called by the dispatcher right after any commit-producing verb and credits the process only when HEAD actually advanced, so a no-op commit with nothing staged and a rejected merge count nothing. zprocs extends the same identity to a per-verb tally (which mutating verbs each agent ran, how often, first- and last-seen), keyed to the same session so it joins straight onto the process row. Basis: zvcs/src/extensions/src/superset/zppid.rs (the responsible-process walk, COMMIT_VERBS, note_commit HEAD-advanced check), the ppids and proc_verbs tables in src/extensions/src/db.rs, the dispatcher hook in dispatch.rs. Caveat: process-ancestry walks are standard systems programming (pstree, ps -f), and git records an author, not a process; the candidate-first is a VCS that makes which running process produced this commit a first-class, queryable dimension — the question that only becomes interesting once a fleet of automated agents shares one tree. Heuristic by construction: an agent that execs through an unusual supervisor may resolve to that supervisor. "None found," not proven; sweep non-exhaustive. A zvcs addition. MIT.

Git keeps no record of commands. Shell history is per-shell, per-user, and unattributed; server-side logs see only pushes. Because zvcs is the sole git on the machine, every invocation passes through one dispatcher, and it logs time, the responsible agent, the repo, and the argv to $ZVCS_HOME/commands.log. zcommands (#182) is the live feed over that log; zaudit is the historical, accountable side: filter by agent, by repo, or by command; restrict to state-changing commands; or aggregate a --summary of who ran what. In a fleet of concurrent agents it answers the question no other VCS tooling can — "which agent ran push --force against which repo, and when" — without instrumenting any of the agents. Off by default; the hot path is a single stat when logging is disabled. Basis: zvcs/src/extensions/src/superset/zaudit.rs (filters, state-changing classification, --summary aggregation), superset/zcommands.rs (the log format and live feed), the log_invocation hook in src/extensions/src/dispatch.rs, agent identity from superset/zppid.rs (#188). Caveat: auditing is a solved problem outside the tool (shell audit daemons, auditd, CI logs, server hooks); the candidate-first is the VCS auditing itself — complete because the binary is the only git, and attributable because it already resolves the responsible process. It records commands run through this binary; a different git on PATH is invisible to it. "None found," not proven; sweep non-exhaustive. A zvcs addition. MIT.

git commit and git push are synchronous: the terminal blocks until the work finishes, and a failure in a scripted batch is a stack of retries. zvcs adds an async lane. git zcommit / git zpush build a job spec, hand it to the daemon over the socket, and return immediately with a job number; the daemon runs it off the caller's critical path in a bounded worker pool (at most n concurrent, the rest queued) and records every transition in the SQLite ledger (queued → running → terminal). Because jobs are ledger rows with cancellation handles, they are controllable: zjob stop aborts a running job by killing its child, or flips a still-queued job to stopped before a worker takes it; zjob restart clones the row, links it by parent_job_id, and re-enqueues it. The join half is a set of coordination verbs — zqueue shows what is in flight, zwait blocks until one repo's jobs drain, zbarrier until the whole queue is idle. Two safety properties matter: a job executes the faithful porcelain by spawning this same binary with the job's workdir as cwd (so async never forks a second implementation of add/commit/push), and if no daemon is reachable the verb runs synchronously in-process and is still recorded, so it always works. zpush additionally does a network-free pre-flight against the remote-tracking ref and refuses a diverged push before enqueue rather than failing asynchronously later. Basis: zvcs/src/extensions/src/superset/queue.rs (spec build, submit, synchronous fallback, pre-flight), src/extensions/src/jobpool.rs (bounded pool + Cancel registry + restart-by-clone), src/extensions/src/jobrun.rs (faithful-porcelain execution), superset/coord.rs (zqueue/zwait/zbarrier), the jobs table in src/extensions/src/db.rs. Test-verified: tests/queue.rs::zcommit_is_queued_executed_and_recorded, tests/jobctl.rs::zjob_restart_and_stop_control, tests/zjobs_limit.rs, tests/zcommit_async_identity.rs. Caveat: job queues are ancient and CI systems run VCS operations asynchronously all the time; the candidate-first is the VCS itself exposing its write verbs as supervised jobs with a durable ledger, cancellation, restart-with-lineage, and a synchronous fallback — where git's model is one process, one operation, one exit code. "None found," not proven; sweep non-exhaustive. A zvcs addition. MIT.

Scripts that coordinate multi-repo work poll: until git status --porcelain | grep -q .; do sleep 1; done, per repo, with no notion of the tree as a whole. git zwaitfor <condition> makes the wait a first-class operation over the daemon's cached fleet state and exits 0 when the condition holds (1 on --timeout): clean — every indexed repo has nothing uncommitted; idle — no queued or running daemon jobs; synced — every repo is up-to-date with its upstream; and <substr> <sha> — the repo whose path contains <substr> is at that commit (prefix match). Where zwait/zbarrier (#190) are job-scoped, this is a barrier on state, which is what an orchestration script actually needs before it proceeds to the next phase. Because it reads the daemon's repo_status cache rather than walking every worktree, the check is constant-cost regardless of fleet size. Basis: zvcs/src/extensions/src/superset/zwaitfor.rs (the four conditions over cached repo_status, timeout handling), fed by superset/statusd.rs (#197). Caveat: barriers and wait-for-condition loops are elementary; the candidate-first is a VCS shipping a tree-wide state barrier as a verb, which presupposes both a machine-wide repo index and a daemon keeping status warm — neither of which exists in stock git. Requires the daemon to be maintaining status; without it the conditions have nothing to read. "None found," not proven; sweep non-exhaustive. A zvcs addition. MIT.

A submodule tree has no single state: the parent records pointers, each submodule has its own HEAD, and putting the whole thing back to "how it was an hour ago" is a manual walk with a reset --hard per repo — if you can even reconstruct the targets. zvcs makes both forms one command. git zsnapshot <name> records the exact HEAD of the current repo and every nested submodule as one named restore point in the ledger; git zrestore <name> puts the entire tree back to those commits, and zsnapshots lists them. git zrewind <duration> needs no prior setup at all: for the repo and every nested submodule it reads each one's reflog, finds the HEAD it had <duration> ago, and resets to it — the whole tree to an arbitrary wall-clock moment, with --dry-run to preview and an explicit report of any repo whose reflog does not reach that far back. Both reuse the faithful ported reset --hard, so the restore is reflogged and therefore itself undoable, and zrewind refuses a dirty repo so uncommitted work is never clobbered. Basis: zvcs/src/extensions/src/superset/snapshot.rs (zsnapshot/zrestore/zsnapshots + the snapshots table), superset/zrewind.rs (per-repo reflog resolution at a timestamp, dry-run, dirty guard). Test-verified: tests/snapshot.rs::snapshot_and_restore_tree builds a real submodule tree, snapshots, moves it, and restores. Caveat: snapshots are the defining feature of other systems (ZFS, Time Machine, git stash-style savepoints) and a monorepo sidesteps the problem entirely; the candidate-first is named and time-addressed restore points over a nested-submodule tree as one unit, inside the VCS, using each repo's own reflog as the time index. zrestore is deliberately destructive to tracked changes (that is what restore means; untracked files survive), and zrewind can only reach as far back as the reflogs do. "None found," not proven; sweep non-exhaustive. A zvcs addition. MIT.

git stash is per-repository and does not reach a submodule's dirty state through the parent, so parking in-flight work across a deep tree means remembering which submodules were dirty and stashing each by hand — and remembering the same list to restore. git zstash [<name>] walks the current repo and every nested submodule, stashes each dirty one through the faithful ported git stash push, and records the whole set under one name (default wip); git zunstash [<name>] pops them back LIFO and zstashes lists what is parked. It complements #192: zsnapshot captures committed HEADs, zstash captures uncommitted work, and together they cover the two halves of a tree's state. The boundary is stated rather than faked: zvcs's git stash pop applies only onto an unchanged HEAD (3-way apply is not ported), so a repo whose HEAD moved in the meantime is reported and its stash kept intact rather than half-applied or lost. Basis: zvcs/src/extensions/src/superset/zstash.rs (tree walk, per-repo stash through the porcelain, the stashes table, LIFO restore, live-name guard). Test-verified: tests/zstash.rs::zstash_parks_and_zunstash_restores and ::zstash_refuses_reusing_a_live_name. Caveat: stashing is core git and multi-repo tools can script a loop; the candidate-first is a single named stash object spanning a whole submodule tree, tracked in a ledger so the set is restorable as one unit. Restore is only guaranteed onto the commits the work was stashed on. "None found," not proven; sweep non-exhaustive. A zvcs addition. MIT.

git reset --hard HEAD@{1} undoes one repo's last operation; across a fleet, undoing a bad batch means running it by hand in every affected repo while deciding, per repo, whether it is safe. git zrollback does the whole selection at once: for every selected repo it resolves HEAD@{steps} from the reflog and rewinds to it — the last commit, merge, rebase, or reset — with three refusals built in. A repo is skipped, not rolled back, when its worktree is dirty (uncommitted work would be lost), when it is mid-operation (an in-flight merge/rebase), or when the rollback would diverge it from its remote (the commits being discarded are already pushed); --force overrides. It is dry-run by default: with no --apply it prints exactly what each repo would do and changes nothing. And because the underlying reset --hard is reflogged, a rollback is itself undoable. Basis: zvcs/src/extensions/src/superset/zrollback.rs (reflog resolution per repo, the dirty / mid-operation / diverged guards, dry-run default, --force), the shared selector grammar in superset/select.rs. Caveat: per-repo undo is git's own reflog and multi-repo runners (mr, gita) can loop a command; the candidate-first is undo as a fleet operation with per-repo safety analysis — the guards are the point, since a blind loop over reset --hard is exactly how a batch mistake becomes data loss. Bounded by what each reflog retains. "None found," not proven; sweep non-exhaustive. A zvcs addition. MIT.

Git's reflog is per repository, so "what happened across this tree in the last hour" has no answer: you would open each repo's reflog and merge them by hand. git zlog merges the HEAD reflogs of every indexed repo into one machine-wide, time-ordered timeline — what moved, where, and when — which is the view a fleet of concurrent agents actually needs. git zundo rewinds a repo one step by reading its previous HEAD from the reflog and resetting to it (reusing the faithful porcelain reset, refusing on a dirty worktree so nothing is clobbered). git zsince <duration|snapshot> answers the delta question directly: everything that happened across the tree since a wall-clock offset (90s, 45m, 2d, 1h30m) or since a named snapshot's creation time, filterable by kind and repo. Basis: zvcs/src/extensions/src/superset/oplog.rs (zlog merge across the repo index, zundo one-step rewind), superset/zsince.rs (duration/snapshot baseline over the event feed), superset/zevents.rs (the append-only events table the window is read from). Test-verified: tests/oplog.rs::zlog_timeline_and_zundo_rewind. Caveat: the reflog is git's; merging logs is elementary; the candidate-first is the VCS treating every repo on the machine as one reflog domain, which requires the repo index and the event feed that only the daemon maintains. Coverage is limited to indexed repos and what their reflogs retain. "None found," not proven; sweep non-exhaustive. A zvcs addition. MIT.

git worktree add gives one repository a second checkout; a submodule tree needs one per repo, wired by hand, and the result is easy to get subtly wrong. git zworktree add <name> provisions a complete private checkout of the current repo and every nested submodule under <base>/<name>/ (default ~/.zvcs/worktrees), each repo a real linked git worktree — its own index, HEAD, and working directory on a fresh zwt/<name> branch — that shares the existing object store, so nothing is re-cloned and stock git recognizes the result (git worktree list, fsck). That is what makes it useful for a fleet: each agent gets a tree that cannot collide with any other, at the cost of a checkout rather than a clone. Because gix has no worktree-creation API, the bookkeeping is written directly in git's format — <gitdir>/worktrees/<name>/{HEAD,commondir,gitdir,index} plus the worktree's .git file — which is why compatibility is a tested property rather than a hope. Basis: zvcs/src/extensions/src/superset/zworktree.rs (tree walk, per-repo linked-worktree creation, the git-format bookkeeping, the worktrees table). Test-verified: tests/zworktree.rs::zworktree_isolated_tree_add_and_remove, ::zworktree_add_writes_absolute_gitdir_for_relative_dest, and ::zworktree_remove_rejects_path_traversal; tests/worktree_reuse.rs covers reuse. Caveat: linked worktrees are git's feature and multi-repo tools can script the loop; the candidate-first is the whole submodule tree provisioned as one isolated worktree by one verb, with the linked-worktree metadata authored directly because the pure-Rust engine offers no API for it. "None found," not proven; sweep non-exhaustive. A zvcs addition (gitoxide engine vendored). MIT.

A dirtiness scan is the expensive part of git status, and doing it on demand across thousands of repos is unusable — which is why every multi-repo tool either shows stale data or blocks. zvcs runs a dedicated daemon pool that never idles: one worker per core, each pulling the next repo off a shared rotating cursor, computing its status, handing the result to a single writer thread, and immediately taking the next — no pauses and no sleep phase, so every repo's status is refreshed every few seconds. The compute/write split is the design point: the expensive worktree scan is parallel and read-only, while one writer batches results into SQLite, because WAL allows a single writer at a time and letting every worker write would thrash the write lock. Everything interactive reads that cache — zdashboard (#187), ztop (#182), zstatus --all, the --dirty/--ahead/--behind selectors, and zwaitfor (#191) — which is what makes those instant and accurate rather than one or the other. Status transitions also write status rows into the event feed via table triggers, so the reactive layer (#184) needs no extra plumbing. Basis: zvcs/src/extensions/src/superset/statusd.rs (the rotating-cursor pool, single-writer batching, repo_status maintenance), the repo_status table and its triggers in src/extensions/src/db.rs. Test-verified: tests/statusd.rs::daemon_keeps_status_cache_warm, tests/status_daemon.rs. Caveat: background indexers are common (Spotlight, IDE indexers, updatedb); the candidate-first is a VCS maintaining a machine-wide freshness invariant over repository state, with the parallel-read / single-writer split that a WAL database forces. It is a cache: a repo is fresh to within a sweep, not instantaneously, and on-screen rows are re-read live for exactly that reason. "None found," not proven; sweep non-exhaustive. A zvcs addition. MIT.

git verify-commit checks one commit in one repo, and "is anything unsigned anywhere in this tree" has no answer short of a scripted loop. git zsigs checks the top -n commits (HEAD by default) of every selected repo and flags any that are not a good signature — unsigned (N), bad (B), or unverifiable (E/X/Y/R) — printing <code> <repo> <sha> <subject> per offender and exiting non-zero if any is found, so it gates a push or a CI stage the way an unsigned-commit policy needs. Verification uses zvcs's shared signature substrate: the signature and the signed payload are reconstructed natively from the object (there is no shell-out to git verify-commit) and then handed to gpg or ssh-keygen — the same tools git itself invokes — so the trust decision stays with the user's existing keyring while the object handling stays in-process. Basis: zvcs/src/extensions/src/superset/zsigs.rs (fleet sweep, status codes, non-zero exit), src/extensions/src/gitsig.rs (native payload/signature reconstruction and the gpg / ssh-keygen bridge), superset/select.rs (scoping). Caveat: signature verification is git's own feature and CI systems enforce signing server-side; the candidate-first is the whole fleet checked in one verb by the VCS binary, with the verification payload rebuilt natively rather than delegated to another git. Trust ultimately rests on the external gpg / ssh-keygen result, and only the top -n commits per repo are inspected. "None found," not proven; sweep non-exhaustive. A zvcs addition. MIT.

Recurring VCS maintenance normally lives outside the tool — a crontab entry, a systemd timer, a CI cron — each of which must re-derive which repos exist and how to reach them. git zsched puts the schedule in the tool: entries live in $ZVCS_HOME/schedule.tsv as id \t interval_secs \t command, and the daemon's scheduler thread fires each one on its interval across the fleet. The concurrency design is the interesting part and is deliberately asymmetric: the CLI owns every write to the file (add / rm / clear) and the daemon thread only ever reads it, tracking last-fire times in memory. That split means the two processes can never contend on the file, and the worst case of a lost in-memory timing update is one schedule firing a tick later — never a corrupted schedule set. Because the thread re-reads the file each tick, zsched add/rm take effect within one tick with no daemon reload. Basis: zvcs/src/extensions/src/superset/zsched.rs (the TSV format, CLI-owns-writes rule, in-memory fire tracking, per-tick re-read), spawn_scheduler there, started by superset/zdaemon.rs:505. Caveat: cron is fifty years old and git maintenance already schedules git's own housekeeping through the system scheduler; the candidate-first is a VCS hosting its own scheduler for fleet-wide verbs, with a single-writer file protocol chosen so scheduling can never race the daemon. Interval-based only — no cron expressions, no calendar semantics — and it fires only while the daemon runs. "None found," not proven; sweep non-exhaustive. A zvcs addition. MIT.

Git recomputes derived data on every invocation: log --stat re-diffs each commit pair, blame re-walks the file's history, and every short SHA is re-derived against the object database. zvcs caches all three in the SQLite ledger — treediff (a tree pair's change list and per-file line tallies), blame (a commit/path/algorithm's run list), and abbrev (an OID's short form at a given length) — and git zprecache fills them for a repository's recent commits before anyone asks, leaving log --stat, --numstat, --shortstat, --name-status, and the abbreviated formats reading from the ledger instead of the object store. The daemon does the same work automatically whenever a watched repo's refs move (zvcs.precache, on by default), so the on-demand verb exists mainly for after a large clone or a fetch that landed while the daemon was down. The correctness argument is what makes this safe to do at all: every cached value is a pure function of immutable inputs — a commit's abbreviation is fixed once the object exists, and a tree pair's change list and line tallies are a pure function of two immutable trees — so there is no invalidation problem to get wrong, and nothing here guesses at what the user will run. Basis: zvcs/src/extensions/src/superset/zprecache.rs (the on-demand warm pass and its --limit/--quiet flags), the treediff / blame / abbrev tables in src/extensions/src/db.rs, src/extensions/src/abbrev.rs, the daemon precache path in superset/watch.rs. Test-verified: tests/precache.rs::warmed_caches_render_exactly_what_the_cold_path_does asserts the warm and cold paths produce identical output — the property the whole feature rests on — plus ::a_single_run_leaves_its_cache_rows_on_disk, ::the_limit_bounds_how_much_is_warmed, ::an_unborn_head_warms_nothing_without_failing. Caveat: git has its own persistent accelerators (commit-graph, midx, fsmonitor, core.untrackedCache) and this is the same idea; the candidate-first is caching rendered derived data — diffs, blame runs, abbreviations — in a queryable database, with the immutability argument that makes staleness structurally impossible, and a verb that warms it ahead of demand. Cache hits require the ledger; a missing or read-only ledger degrades to the normal compute path. "None found," not proven; sweep non-exhaustive. A zvcs addition. MIT.

Git's diff machinery is single-threaded: git log -p over a thousand commits renders every patch on one core while the rest of the box idles, and nothing about the work requires that — each entry is an independent tree-to-tree diff over objects that are immutable for the duration of a read-only command. zvcs fans that work out. Patch bodies for a batch of commits are rendered in parallel, and so are the per-delta bodies within a single large diff; workers pull from a shared cursor rather than taking a fixed slice, because one commit that rewrites a large file costs more than a hundred that touch a line each and a static split would leave every worker but that one idle. Two rules keep it from backfiring: a batch must carry a minimum number of items per worker (four commits; two deltas) or the sequential path is taken outright, and the worker count is capped by the machine's parallelism and pinned exactly by ZVCS_THREADS (1 forces sequential) — because CI containers report the host's core count through available_parallelism while being cgroup-limited to far less, and benchmarks need the variable held still. Since neither gix::Repository nor the blob platform is Sync, each worker owns a handle clone that shares the underlying object store, so parallelism costs a handle rather than a re-open. Basis: zvcs/src/extensions/src/porcelain/diff.rs (commit_patches batch renderer and the per-delta fan-out), src/extensions/src/porcelain/log.rs (render_span parallel entry blocks), src/extensions/src/threads.rs (the min_per_thread rule, available_parallelism cap, ZVCS_THREADS override). Caveat: parallelism is not a novel idea and git parallelizes elsewhere (pack-objects, index-pack, fsmonitor, checkout); the candidate-first is specifically the diff/log rendering path, which upstream leaves single-threaded, being fanned across cores in a git-compatible binary. Output order is preserved and byte-parity with stock git is asserted by the #174 harness, so this is a pure latency change; gains are workload-dependent and small batches deliberately stay sequential. "None found," not proven; sweep non-exhaustive. A zvcs addition (gitoxide engine vendored). MIT.

A binary that invents 116 verbs stock git never had has a documentation problem no upstream man page can solve, and a compatibility problem the moment it replaces git on PATH: nothing else provides the dashed git-<verb> external forms tools still expect. zvcs generates both from its own dispatch tables. superset/manpage.rs holds one structured Doc per verb and renders real man(1) roff on demand, so git help zsync works with no prior setup, while git zdashed writes a git-<verb> symlink for every builtin and superset verb into ~/.zvcs/bin — the verb set read from PORCELAIN_VERBS + SUPERSET_VERBS, never hardcoded — idempotently (a correct symlink is left alone, a stale one repointed, a real file never clobbered). git zverbs lists the live table, and git zdoctor checks the installation end to end: is this binary the git on PATH, is $ZVCS_HOME present, is the coordinator running, is there a ledger, are the man pages and dashed symlinks installed, is ~/.zvcs/man on MANPATH — each OK/WARN/FAIL, exiting non-zero only on a hard failure so it is scriptable. The anti-drift property is enforced, not aspirational: tests fail the build when the documentation and the dispatch tables disagree. Basis: zvcs/src/extensions/src/superset/manpage.rs (the DOCS table and roff renderer), superset/dashed.rs (symlink installer driven by the dispatch tables), superset/doctor.rs, the zverbs verb (print_verbs, with --json for scripting and --html emitting the full docs/reference.html) in src/extensions/src/dispatch.rs. Test-verified: tests/manpage.rs::docs_cover_exactly_the_superset_verbs (no verb undocumented, no doc orphaned), ::html_reference_covers_every_verb, ::roff_has_the_mandatory_sections, ::install_all_writes_one_page_per_verb; tests/zverbs.rs::zverbs_lists_every_superset_verb; tests/docs_freshness.rs::quoted_verb_counts_match_the_dispatch_tables and ::documented_zvcs_switches_match_the_ones_the_tree_reads fail when prose counts or documented switches drift from the code. Caveat: generated man pages and shell-completion generators are common (clap, help2man); the candidate-first is the closed loop — one dispatch table is simultaneously the router, the man-page index, the symlink source, the health check, and the thing tests assert documentation against — in a binary that replaces git. "None found," not proven; sweep non-exhaustive. A zvcs addition. MIT.

Stock git's credential helpers are separate executables — git-credential-osxkeychain, git-credential-store, git-credential-cache plus its --daemon, and the contrib git-credential-netrc Perl script — resolved off PATH and shipped, or not shipped, by whoever packaged git. zvcs implements all of them as verbs of the single multicall binary, so a machine with zvcs as its git has the full set by construction, cross-compiled with it: credential (fill/approve/reject), credential-osxkeychain, credential-store, credential-cache, credential-cache--daemon, and credential-netrc. The keychain helper is a port of git's git-credential-osxkeychain.c over Security.framework and carries two behaviors the original contrib helper does not: it updates an existing item instead of silently keeping the old secret on re-store (upstream's add-only version leaves a rotated credential permanently stale), and it suppresses the write entirely when the secret has not changed — both via git's own capability[]/state[] protocol and via a compare-before-write on the stored value, because a keychain write is a separate authorization from a read and rewriting an unchanged item on every fetch and push re-raises the macOS authorization dialog on each operation. It also stores password_expiry_utc and oauth_refresh_token in the item's data blob as upstream does, so an expiring OAuth token is refreshed on schedule rather than after it starts failing. Basis: zvcs/src/extensions/src/porcelain/credential_osxkeychain.rs (the Security.framework port, encode_state_seen, the duplicate-item compare-before-write, the expiry/refresh blob, upstream's O_EXLOCK self-lock), credential.rs, credential_store.rs, credential_cache.rs, credential_cache__daemon.rs, credential_netrc.rs, routed from src/extensions/src/dispatch.rs. Test-verified: porcelain::credential_osxkeychain::tests covers the state-token encoding and the stored-secret layout (state_token_matches_upstream_encoding, state_from_get_blob_survives_the_round_trip_to_store, rotated_password_changes_the_state_token, secret_blob_appends_expiry_and_refresh_token_as_protocol_lines); tests/credential_config.rs covers helper configuration. Caveat: credential helpers are git's own design and the protocol is git's; the candidate-first is the complete suite living in one binary rather than as separately-packaged executables, plus the write-suppression behavior, which is a correctness/UX fix over the contrib helper rather than a new capability. The keychain path is macOS-only by construction (it compiles to no-ops elsewhere, as git's helper is macOS-only too). "None found," not proven; sweep non-exhaustive. A zvcs addition. MIT.

Stock git's index.lock is O_EXCL: a contended writer does not wait, it fails (fatal: Unable to create '.git/index.lock': File exists), which under many concurrent writers is a thundering herd of retries with no fairness. #173 replaces that with a daemon FIFO for zvcs's own writers, but a mixed machine still has foreign lock holders — an IDE, a stock git invocation, another tool — and the FIFO cannot serialize what it does not mediate. So zvcs adds the missing half: before an index-mutating operation it waits for a foreign <git-dir>/index.lock to clear, within a budget (ZVCS_INDEX_LOCK_WAIT_MS, 0 disabling the wait entirely), and only if the lock outlasts the budget does it fall back to queueing behind the coordinator. The common case — a foreign writer holding the lock for milliseconds — becomes patience rather than a failure, which is what a scripted batch needs. The coordinator guard itself is RAII: dropping it on normal return, ?, or panic sends RELEASE, and the daemon auto-releases on socket EOF, so a crashed holder can never wedge a repo; with no daemon reachable it degrades to a no-op guard and the operation runs exactly as stock git would. Basis: zvcs/src/extensions/src/lock.rs (wait_for_foreign_index_lock with the ZVCS_INDEX_LOCK_WAIT_MS budget, RepoLock::acquire, the RAII Drop that emits RELEASE, the no-daemon no-op path). Test-verified: tests/index_lock_queue.rs::waits_out_a_foreign_lock_that_clears, ::queues_when_the_lock_outlasts_the_wait, ::a_queued_rerun_never_requeues_itself, ::zero_wait_disables_the_budget; tests/lock_reentrant.rs; tests/daemon_race.rs::concurrent_start_on_stale_socket_yields_one_daemon. Caveat: waiting on a lock is elementary and other VCSs block by default; the candidate-first is a git-compatible binary that keeps git's on-disk lock protocol (so stock git and IDEs interoperate with it byte-for-byte) while replacing the failure semantics with waiting and, beyond the budget, with a fair queue. It cannot make a foreign writer fair — only patient toward it. "None found," not proven; sweep non-exhaustive. A zvcs addition. MIT.

Git has no concept of a peer. When N automated agents share one tree, everything they need to avoid stepping on each other has to be invented outside the VCS. zvcs puts that plane in the binary, on the shared ledger. Leases: git zclaim records "this session is working this repo", zunclaim releases, zwho lists holders; the claim is race-safe via a primary key and attributed to the caller's session, and it is deliberately advisory — it coordinates intent, while physical serialization stays with the FIFO lane (#173). Messaging: git zbroadcast posts a message to every session or one (--to), and with no arguments prints this session's unread messages and marks them read — a pull inbox, so peer messaging costs nothing on the hot path; git zhandoff <repo> <session> reassigns a claim to another agent and leaves it a note. Contention: git zcontend joins three reads — who holds which lease, each repo's queued/running job depth, and their intersection — to answer "who is stepping on whom", the actively contested repos being exactly those both claimed and backed up. Topology: git zgraph shows the relationship git cannot see at all, because git only ever knows one repo: which local checkouts are the same upstream (a dup group — one origin URL, N working trees), which is how a fleet discovers that two agents are editing the same project in different directories. Basis: zvcs/src/extensions/src/superset/claim.rs (zclaim/zunclaim/zwho over the claims table, session identity from crate::session_key), superset/zbroadcast.rs (the messages/message_reads tables, zhandoff), superset/zcontend.rs (claims × job backlog), superset/zgraph.rs (origin-URL dup groups). Test-verified: tests/claim.rs::claim_is_exclusive_across_sessions, tests/claim_force.rs, tests/select_filters.rs::selector_dirty_and_claimed_filters, tests/session_key.rs. Caveat: advisory locking (flock, lease services), message queues, and dependency graphs are all long-established; the candidate-first is a VCS carrying an agent-coordination plane natively — leases, inbox, contention analysis, and same-upstream topology as verbs of the git binary, on the same ledger its other fleet verbs read. Advisory by design: a claim does not block a writer, and an agent that ignores the plane is unaffected by it. "None found," not proven; sweep non-exhaustive. A zvcs addition. MIT.

Filtering a selection through an external command is one of the oldest moves in text editing — ! in vi, M-| in Emacs — and it has always cost the same thing: a three-stage awk | ruby | php filter is three fork+execve pairs, six pipe descriptors, three waitpids and a full encode/decode of the text at every boundary, for interpreters that in this stack are already linked into the editor binary. :xpipe runs the same chain as N function calls on the editor thread. Twelve runtimes are addressable as stages — awk, arb, ruby, python, node, php, rlang, tcl, zsh, stryke, elisp, vim — with no process created, no pipe opened, and the whole chain landing as one undo step. The part that makes it more than a speed trick is the binding: each stage receives the incoming text as a real value on that stage's own runtime — a Ruby String, a Python str, a JS string, a PHP variable, an R character vector, a Tcl global, a zsh parameter, a stryke scalar, an elisp symbol value, a VimL g: variable — which cost work upstream rather than in the editor, because every frontend's eval_str resets its host and wipes a global installed beforehand. Each therefore grew an entry point that seeds bindings after the reset and captures output in-process (eval_str_captured in rubylang, pythonrs and node-js, eval_capture_with in phplang, eval_captured in rlang, bind_scalar + begin_capture in strykelang, execute_script_captured in zshrs, set_global_string in vimlrs; elisp needed nothing new). Stages are separated by a whitespace-delimited |> — a language constraint, not a style choice, since a bare | is live syntax in most of the twelve (awk's print | "cmd", Ruby and JS block parameters, zsh pipelines). And the threading rule falls out of the runtimes rather than being asserted: Stage::is_pure is true only for awk and arb — the two that build a fresh runtime per call and touch nothing shared — and Pipeline::is_pure folds it with all, so a chain leaves the editor thread only when every stage can. Basis: zmax/zmax-term/src/commands/scripting/pipeline.rs:60-62 (the twelve-name LANGUAGES table), :89-91 (Stage::is_pure = Awk | Arb, with the per-language reasons the other ten are pinned), pipeline.rs:1-56 (the per-frontend capture entry points and why the reset forced them); zmax/zmax-term/src/commands/scripting/mod.rs:730 (Pipeline::is_pure folding with all). Caveat: editors have embedded a scripting language for decades (Emacs/elisp, vim/VimL, Sublime/Python, VS Code/JavaScript), and multi-language plugin hosts exist — but they host each language in a separate process or VM instance and marshal across the boundary. The novelty is the conjunction: twelve, chained, in-process, value-bound, one undo step. Ten of the twelve are pinned to the editor thread (thread-local interpreter state; zsh's capture swaps process fds; elisp and VimL reach the editor through a thread-local raw pointer), so the parallel path is awk/arb-only chains. Overlaps #120, which is the embedding; this is the chaining. "None found," not proven; sweep non-exhaustive.

imsg is OpenBSD's IPC framing — the message layer its privilege-separated daemons are built on, vendored into portable tmux as the server↔client channel. The Rust ecosystem talks to tmux the other two ways: through the CLI (tmux_interface, 150,555 downloads, its own one-liner is "Rust language library for communication with TMUX via CLI" — build a command line, run the tmux binary, parse the text back), or through C. ztmux does neither: it ports imsg itself. src/ported/compat/imsg.rs (700 L, 27 public fns) plus imsg_buffer.rs (1,699 L, 65 public fns) — 2,399 Rust lines, 92 public entry points — reimplement the 1,703 vendored C lines of imsg.c / imsg-buffer.c / imsg.h: the ibuf/ibufqueue/msgbuf machinery, header-callback framing, size and overflow accounting, and SCM_RIGHTS fd passing, with no bindgen, no C shim, and no link against a system imsg (the build script's own words: "ztmux has no C libraries to find or link"; the only C-adjacent dependency in Cargo.toml is libc for syscalls). What makes it current-generation is the target: the vendored sources are $OpenBSD: imsg.c,v 1.42 2025/06/16, imsg-buffer.c,v 1.36 2025/08/25, imsg.h,v 1.24 2025/06/05 — the post-2023 rewrite where write/read state lives in a heap struct msgbuf reached through imsgbuf->w, framing is driven by an imsg_parse_hdr callback instead of an embedded read buffer, and stack buffers are marked IBUF_FD_MARK_ON_STACK rather than max == 0. The only other Rust imsg port found — tmux-rs, the repo ztmux was seeded from — predates that rewrite: of six markers of the new API, msgbuf_new_reader, imsg_parse_hdr, ibufqueue and IBUF_FD_MARK_ON_STACK appear 0 times in its src/compat/imsg.rs (570 L) + imsg_buffer.rs (661 L), against 5 / 4 / 29 / 13 in ztmux's. The port is load-bearing, not vendored decoration: src/ported/proc.rs runs the real server↔client loop on imsgbuf_read / imsg_get / imsg_compose / imsg_get_fd, and because the anti-drift gate (#175) covers vendor/tmux/compat/*.c, every ported fn name is build-checked against the C. The client half is independent and entirely safe Rust: ztmux-core/src/transport.rs writes the 16-byte native-endian imsg header (type, len, peerid, pid) straight onto an AF_UNIX/SOCK_STREAM socket with PROTOCOL_VERSION = 8 carried in peerid, so zterminal is a first-class tmux client with no tmux subprocess and no output scraping anywhere in the path — the GUI reads command output over the file protocol (MSG_WRITE_OPEN → MSG_WRITE → MSG_EXIT), not off a pipe. Basis: ztmux/src/ported/compat/imsg.rs:1 (the port header naming imsg.c,v 1.42 / imsg.h,v 1.24 and the three generation changes) and imsg_buffer.rs; ztmux/vendor/tmux/compat/imsg.c:1, imsg-buffer.c:1, imsg.h:1 (the vendored revisions); ztmux/src/ported/proc.rs:16-106 (live use); ztmux/build.rs:1-5 (no C to link) + ztmux/Cargo.toml:52 (deps: libc only); commit 202d62952c "port: re-port imsg to the vendored (new) OpenBSD API"; ztmux/tests/ported_fn_names_match_c.rs:224 (gate scope includes vendor/tmux/compat/*.c); ztmux-core/src/transport.rs:7-128 (safe-Rust framing, PROTOCOL_VERSION = 8, the file protocol). Prior-art sweep (2026-08-18): GitHub code search imsg_compose language:Rust returns 4 hits in 2 repositories — richardscollin/tmux-rs and MenkeTechnologies/ztmux — and a crates.io search for imsg returns only iMessage/Bluetooth-MAP crates, no OpenBSD-imsg crate. Caveat: not "first imsg in Rust" — tmux-rs precedes it, and ztmux was seeded from tmux-rs; the candidate-first is narrower: the current-generation API (roughly 2× the surface) ported in pure Rust, plus a native-imsg tmux client engine. Nearest non-tmux prior art is privsep 0.0.2 (reyk/privsep-rs, privsep/src/imsg.rs, 274 L, last published 2021-09-18), which is imsg-inspired — tokio UnixStream + serde payloads + a zerocopy header — not a port of the C API (no ibuf/msgbuf queues, no imsg_compose/imsg_flush surface), and its README calls the crate "experimental and WIP". The ztmux port is a faithful unsafe transliteration (65 and 168 unsafe occurrences in the two files) that mirrors the C's pointer semantics for parity — not an idiomatic safe-Rust redesign; the safe half (ztmux-core) implements only the client framing subset, with no fd passing and no write queue. imsg is OpenBSD's design (ISC) — the claim is the port and the CLI-free client path, not the protocol. Sweep was crates.io + GitHub code search only; "none found," not proven. MIT (derivative of tmux, ISC).

Git's only extension point for a third party is the dashed external: name an executable git-foo, put it on PATH, and git foo will exec it (execv_dashed_external, git.c). There is nothing else — no installer, no registry, no in-process API, no way to replace a built-in verb, and every invocation is a fork of a separate program that then talks to git by running git again. The neighbours each have one half and not the other. Mercurial has genuine in-process extensions, but they are Python source enabled by hand in an hgrc [extensions] section and obtained however you like — there is no package manager in hg. GitHub CLI has the package manager — gh extension install owner/repo, --pin, even precompiled binary extensions — but gh is not a VCS and its extensions are still separate executables it forks, with no ABI and no ability to override a built-in command. zvcs has both halves at once, inside the git binary: git znative add|load|remove|list|info|update|gc installs plugins into one content-addressed global store under $ZVCS_HOME/pkg (sources auto-classify — owner/repo, github:…, git+URL, path:…, with @ref pinning — and each install is SHA-256 pinned in installed.toml), and a native plugin is a Rust cdylib compiled against the versioned znative C ABI and dlopened into the running git, registering verbs that dispatch in-process. A plugin may also override an existing verb — its handler runs in place of the built-in implementation and calls dispatch_verb to run the original — which git's fork-an-external model structurally cannot express. The host API a plugin calls back through is the VCS, not a shell: run (any subcommand, in this process, no fork), config_get/config_set, repo_info, resolve_rev, object_read/object_write. Script plugins — a repo of git-<verb> executables, the shape every existing third-party subcommand already ships in — install into the same store from the same command, so the manager is additive rather than a replacement ecosystem. The interesting engineering is the load model, and it is not inherited from the shell original: a shell loads its plugins once into a process that lives for hours, while git is a fresh process per command, so nothing is loaded until a verb proves to belong to a plugin. The verbs a native plugin registers are discovered by loading it once at install time — never declared, so the recorded set cannot lie — and projected into two flat side tables (verbs.tsv, overrides.tsv) that are deleted rather than written empty; a machine with no plugin installed therefore pays two failed stats per command and never opens a file. Basis: zvcs/ZNATIVE.md (command, store and ABI surface); zvcs/src/plugin/src/lib.rs (the dependency-free ABI crate — #[repr(C)] HostApi/PluginInfo/ObjectBuf, MAGIC, ABI_VERSION, INIT_SYMBOL, declare_plugin!); zvcs/src/extensions/src/plugin_host.rs (dlopen via libloading, the magic + version gate, staging buffers, verb/override registries, purge-before-dlclose unload, the side-table lookup); zvcs/src/extensions/src/pkg/ (manifest.rs, store.rs, resolver.rs, commands.rs) + superset/znative.rs; the resolution hook ahead of external::try_dashed in src/extensions/src/lib.rs and the override hook in dispatch.rs; zvcs/examples/ — plugin-hello (added verb + an override that delegates), plugin-wip (git wip, composing add/commit through host.run), plugin-todo (the script kind). Test-verified: zvcs/src/extensions/tests/znative_plugin.rs drives the real git binary through install, plugin-verb dispatch, override-then-delegate, precedence over a same-named git-hello on PATH, the script kind, and the cold case that asserts neither side table exists when nothing is installed. Caveat: every ingredient exists somewhere — dlopen plugin hosts are ancient, hg has in-process extensions, gh has an extension installer, and this project's own zshrs shipped the ABI (#40c) and the compiled-plugin package manager (#40d) first, from which this is ported. The candidate-first is the combination in a version control system: a VCS that ships its own plugin package manager, installs compiled plugins over a stable versioned ABI, runs them in-process, and lets one replace a built-in subcommand — with a per-process discovery model that keeps the cost at two stats when unused. Prior-art sweep found no VCS with a built-in plugin package manager of any kind; "None found," not proven, and searches are not exhaustive. A zvcs addition (ABI and manager ported from zshrs's znative). MIT.

tmux has no plugin API. Its only extension point is run-shell, so every plugin ever published is a shell script that drives the server by shelling out to tmux bind-key …, and the manager everyone uses (TPM) is a third-party shell script that clones repos into ~/.tmux/plugins and runs their *.tmux files. The multiplexers that do have a plugin system each stop short of a different half. Zellij has both a plugin system and a plugin manager, but its plugins are sandboxed WASM modules talking protobuf across a host boundary, loaded from file:/http(s):/zellij: URLs or a plugin directory; its documented API is events, exported commands, filesystem access and async workers — a plugin renders its own pane and issues existing actions, with no documented way to register a new zellij verb or a status-bar variable, and its "plugin manager" is a loader/monitor rather than a store with ref pinning and integrity hashes. WezTerm clones plugin repos from git URLs (wezterm.plugin.require, plugin.list(), plugin.update_all()) but they are Lua applied to the config at startup — a fetcher, no ABI, nothing compiled. kitty's kittens are Python/Go terminal programs run as overlay processes that drive kitty over remote control, with no ABI and no manager. ztmux has the compiled half and the manager half at once, inside the server: a plugin is a Rust cdylib compiled against the versioned [ztnative](https://github.com/MenkeTechnologies/ztmux/tree/main/ztnative) C ABI and dlopened into the running server, and what it registers are the host's own primitives — a command that is a real cmd_entry in tmux's command table, so tmux's own args_parse parses the plugin's flags from the template it declared and the command works from .tmux.conf, a key binding, the command prompt and the CLI alike; a #{…} format provider consulted during expansion, so a plugin extends the format language the status line is drawn from with no shell job on the redraw path; and a hook subscription called from notify_add. It calls back for print/error to the client that ran it, run (parse and queue any tmux command text), get_option/set_option (including the @user options plugins configure themselves with), and format_expand against the running command's target. znative add|load|remove|list|loaded|info|update|gc|clean installs into one content-addressed store under $ZTMUX_HOME/pkg — sources auto-classify (owner/repo, github:…, git+URL, path:…, each with @ref pinning), every install SHA-256 pinned in installed.toml — and the same command installs unmodified TPM plugins into the same store, so the manager is additive rather than a replacement ecosystem. Three parts are specific to a multiplexer and are not inherited from the shell original. Long-lived references force the unload discipline: a parsed tmux cmd holds its cmd_entry by reference for as long as it sits in a command list, key binding or menu, which outlives the plugin — so entries are leaked deliberately, registrations are purged before the dlclose, and every dispatch resolves its handler by name at call time, turning "plugin removed under a queued command" into a diagnostic instead of a jump into an unmapped page. The redraw path sets the cost floor: format and hook dispatch sit behind a relaxed atomic, so a server with no native plugin pays one atomic load per #{…} resolution and never takes a lock. A script plugin has to reach the right server: TPM plugins call bare tmux, so znative runs them with a generated tmux shim first on PATH that execs this ztmux against this socket — necessary because ztmux deliberately adopts $TMUX only for a socket in its own directory (so a ztmux command inside a real tmux pane does not speak ztmux's protocol at a tmux server), which would otherwise leave a plugin on a -S/-L server configuring the default one. A native plugin's identity also comes from the compiled artifact when the repo declares none: the cdylib is probed for its PluginInfo before installation, so a repo called tmux-battery whose plugin declares itself battery installs as battery@0.2.0. Basis: ztmux/docs/ZNATIVE.md; ztmux/ztnative/src/lib.rs (the dependency-free ABI crate — #[repr(C)] HostApi, PluginInfo, HookEvent, ABI_VERSION, INIT_SYMBOL, declare_plugin!); ztmux/src/extensions/plugin_host.rs (dlopen via libloading, the version gate, staging buffers, command/format/hook registries, the leaked cmd_entry + shared exec trampoline, purge-before-dlclose unload, probe); ztmux/src/extensions/pkg/ (manifest.rs, store.rs, resolver.rs, commands.rs, cmd_znative.rs); the three wiring points in the port — src/ported/cmd.rs (CMD_TABLE 92 → 93, and the cmd_find overlay consulted only after the static table misses), src/ported/format.rs (format_find), src/ported/notify.rs (notify_add); ztmux/examples/plugin-hello/ (a complete plugin — one command, one format, one hook). Verified end to end against a live server: install/load/list/loaded/info/remove/ update/gc/clean, the example plugin's command and alias dispatching, its format resolving, its session-created hook firing, an unmodified TPM plugin (tmux-fzf-url) binding its key against the correct server, the two-start .tmux.conf flow, and a plugin trying to register new-window being refused. Caveat: the ingredients are individually old — dlopen plugin hosts are ancient, zellij already ships a multiplexer plugin system, wezterm already fetches plugin repos, and this project's own zshrs shipped the ABI (#40c) and the compiled-plugin package manager (#40d) first, from which this is ported (the sibling port into a VCS is #212). The candidate-first is the combination in a terminal multiplexer: compiled in-process plugins over a stable versioned ABI that register the host's own commands, formats and hooks, plus a package manager in the binary that installs them and the existing shell-script ecosystem from one pinned store. The scoping against zellij rests on its published plugin docs (WASM modules; events/commands/filesystem/workers), not on reading its source. "None found," not proven; prior-art sweep non-exhaustive. A ztmux addition, alongside #175. MIT (ztmux is a derivative of tmux, ISC).