sl0ppi.git/.gitignore, 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.

checks: ignore pycache (the up check imports a sibling check)

2026-08-13T19:19:27Z

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: 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

chore: initialize sl0ppi monorepo