sl0ppi.git/packaging/install.sh, branch main

release: 0.1.9, with a bun that runs without AVX2

2026-08-13T20:51:59Z

The tarball shipped bun's default x64 build, which requires AVX2 -- so sl0ppi installed cleanly on a plain KVM guest and then died with "Illegal instruction" the first time anything ran pi. Known since 0.1.7 and carried as an open item; not something to ship a third time. packaging/fetch-vendor.sh now fetches bun-linux-x64-baseline.zip. Verified without needing such a machine, on an emulated CPU that has none: qemu-x86_64 -cpu Nehalem /bun --version -> 1.3.14 qemu-x86_64 -cpu Nehalem /bun --version -> Illegal instruction Also drops the installer's closing note about the status bar asking for permissions on first launch: shipped plugins are granted implicitly now, so the prompt it told people to expect no longer appears. (That text is baked into the 0.1.9 tarball; it is wrong but harmless, and corrected for the next one.) And gitignores *.core -- qemu writes one where you stand when it kills a target on an illegal instruction, and a 100MB core dump nearly went into this commit. 0.1.9 contains everything since 0.1.8: the split button actually visible and clickable where it is drawn, including on stacked panes; shipped plugins not asking for permission; the status bar as a framed box in the pane style with a new-tab button and margins matching the pane gap, collapsing to a single line in the mobile layout; and runtime tabs keeping a status bar without losing the purpose the CLI uses for identity.

build: ship the sl0ppi CLI in the tarball

2026-08-12T20:51:23Z

The artifact was stale twice over: it predated the protobuf fix and did not contain the CLI at all. Both fixed, and the whole chain re-verified from the tarball rather than assumed. The CLI ships as a single 31K file (`bun build --target=bun`) run by the bundled bun, rather than a source tree or a second `--compile`d binary that would embed another 90M copy of bun. `install.sh` generates the wrapper and pins SL0PPI_BIN to the sl0ppij it just installed, so the orchestrator can never end up driving some other zellij that happens to come first on PATH. Verified in a throwaway HOME with node, npm, bun, cargo, rustc and python3 all replaced by poison stubs that fail loudly if invoked: sl0ppij --version -> 0.45.0+sl0p1 (static musl, no libc dependency) pi --version -> 0.84.1 (bundled bun) sl0ppi doctor -> all good sl0ppi init x2 -> two projects scaffolded sl0ppi up -> session "dev", 2 tabs, agents suspended sl0ppi ls -> agent:suspended, 1 pane each sl0ppi up (again) -> "up to date" And the promise the whole thing exists for, end to end: attach a client, press Enter in the suspended agent pane, and pi starts on the bundled runtime -- while the other project's agent stays suspended, because only the focused pane got the key. `make test` now runs the CLI suite alongside the Rust ones, so the two halves cannot drift apart unnoticed.

build: ship sl0pstatus, and install every plugin the package carries

2026-08-12T18:46:39Z

Phase 3: `make package` now produces a tarball that provably works on a machine with no node, npm, bun or rust. Two bugs the clean-room test found, neither visible until a session actually started: - the default layout builds its status bar out of zjstatus, which we were not shipping at all (vendored as sl0pstatus/ in the preceding commits) - install.sh installed a hardcoded plugin list, so zjstatus.wasm would not have reached the config dir even once staged Also: layouts/*.kdl still pointed at ~/.config/zellij, missed by the rename pass because that pass only rewrote config.kdl. Verified end to end, from the tarball, in a throwaway HOME with node/npm/bun/ cargo shadowed by stubs that fail loudly if invoked: sl0ppij --version -> sl0ppij 0.45.0+sl0p1 pi --version -> 0.84.1 (on the bundled bun) pir --help -> ok sl0ppij -s realtest -> session starts under a pty, config "Well defined", fork pane titles render, both wasm plugins load, no errors beyond the first-run permission cache Artifact: sl0ppi-0.1.0-x86_64-linux.tar.gz, 83M, + .sha256.

build: follow the rename through config, packaging and docs

2026-08-12T18:03:19Z

config/config.kdl plugin path -> ~/.config/sl0ppij/plugins, builtin plugins -> the sl0ppij: URL scheme. Verified to load under the renamed binary ("[CONFIG FILE]: Well defined."). install-config.sh syncs to ~/.config/sl0ppij install.sh a stock zellij on the target is no longer a warning, it is just a fact: the two coexist stage.sh drops the "renaming at package time is a fig leaf" note Makefile builds `-p zellij` (package) and ships `sl0ppij` (binary); `make check` now also gates the root package, using the prebuilt asset plugins so it does not need debug wasm docs/ rename.md records what was done, what was deliberately left (plugin-internal strings live in prebuilt wasm), and the verification actually performed

build: scaffold versioning, docs and the packaging pipeline

2026-08-12T17:39:44Z

Adds the layer that makes this a distributable product rather than three directories: VERSION one sl0ppi version for the whole monorepo FORKS.md what each component is based on, and how to rebase the fork Makefile build / vendor / stage / package, plus dev-box helpers packaging/ fetch pinned payloads, assemble an install tree, install it docs/ architecture, the rename plan, the roadmap The self-contained runtime question is settled and verified: pi upstream builds its own release binary with `bun build --compile`, and a vendored bun runs the vendored pi dist unmodified, so the tarball carries bun + pi and needs no system node, npm or rust on the target machine. packaging/install.sh does a per-user install under ~/.local, never clobbers an existing config (writes .new alongside, or backs up under --force-config), and warns loudly when a stock zellij is present -- because until docs/rename.md is implemented the binary is still zellij underneath and would collide with it.