# Forks and pins

sl0ppi ships **one version** (see `VERSION`), but it is assembled from upstream
projects we fork or pin. This file is the transparency record: for every
component, what it is based on and how far it has drifted.

Keep this file honest. Update it in the same commit that moves a base.

## Vendored forks

### sl0ppij ← zellij

| | |
|---|---|
| upstream | https://github.com/zellij-org/zellij |
| upstream version | `0.45.0` |
| upstream base commit | `0e6e4404` — *Support the Kitty Image Protocol (#5428)*, 2026-07-31 |
| our version string | `0.45.0+sl0p1` |
| lives at | `sl0ppij/` |
| patches on top | 62 commits (all prefixed `sl0p:`) |
| license | MIT (upstream `sl0ppij/LICENSE.md` retained) |

The 62 fork commits were replayed into `sl0ppij/` from the standalone fork repo
(`ssh://git@git.sl0p.foo:39327/srv/git/sl0ppij.git`, branch `sl0p/base`), so
`git log --oneline sl0ppij/` is the patch series. Upstream's own 3311 commits
were squashed into a single vendor import to keep the monorepo small.

#### How to rebase onto a new zellij release

The fork commits live under a `sl0ppij/` prefix here, which upstream's tree does
not have, so a rebase happens *outside* the monorepo and comes back as patches:

```bash
# 1. in a scratch clone of the standalone fork repo
git remote add upstream https://github.com/zellij-org/zellij   # if missing
git fetch upstream
git rebase --onto upstream/main <old-base> sl0p/base           # resolve conflicts

# 2. re-import into the monorepo
git -C <fork> archive <new-upstream-base> | tar -x -C sl0ppij/  # new vendor import (own commit)
git -C <fork> format-patch --binary -o /tmp/p <new-base>..sl0p/base
git am --directory=sl0ppij /tmp/p/*.patch

# 3. verify the import is byte-identical, then update this file
test "$(git rev-parse HEAD:sl0ppij)" = "$(git -C <fork> rev-parse sl0p/base^{tree})"
```

The standalone fork repo stays alive purely as the rebase workbench; the
monorepo is authoritative for what ships.

### sl0pstatus ← zjstatus

| | |
|---|---|
| upstream | https://github.com/dj95/zjstatus |
| upstream version | `0.24.0` |
| upstream base commit | `74f36b4` — *chore: bump version to v0.24.0*, 2026-07-15 |
| lives at | `sl0pstatus/` |
| patches on top | 3 commits (double-click a tab to rename; a new-tab button and pane-gap margins; the bar as a framed box) |
| builds to | `zjstatus.wasm` (cargo package name is still `zjstatus`) |
| standalone repo | `ssh://git@git.sl0p.foo:39327/srv/git/sl0pstatus.git`, branch `sl0p` |

Not optional decoration: `config/layouts/default.kdl` replaces zellij's stock
tab-bar and status-bar with this plugin, so without it the default layout starts
with a "failed to load plugin from disk" error and no status bar.

It depends on the *released* `zellij-tile` 0.44.3 from crates.io, not on
sl0ppij's in-tree one — the plugin API is stable across that gap. Our build
reproduces the previously hand-built `zjstatus.wasm` in the live config dir
byte-for-byte.

Fork-only config keys, all inert when unset (upstream renders identically):

| key | what it does |
|---|---|
| `margin_left` / `margin_right` | blank columns at each end, so the bar lines up with panes inset by the pane gap |
| `new_tab` | format for the `{new_tab}` widget, a clickable button that opens and focuses a tab |
| `bar_frame_enabled` | draw the bar as a box in the pane style, when its pane has 3+ rows |
| `bar_frame_rounded` | `╭╮╰╯` vs `┌┐└┘`; keep in step with `rounded_corners` in config.kdl |
| `bar_frame_format` | style for the box glyphs (we use the theme's `frame_unselected`) |

**Its tests do not run under `make test`.** The crate builds for
`wasm32-wasip1` and `.cargo/config.toml` points the test runner at `wasmtime`,
which is not installed here. Run them against the host instead:

```bash
cd sl0pstatus && cargo test --lib --target x86_64-unknown-linux-gnu
```

Same rebase procedure as sl0ppij, with `sl0pstatus/` as the prefix.

## Pinned, not forked

### pi (the agent)

| | |
|---|---|
| upstream | npm `@earendil-works/pi-coding-agent` |
| pinned version | `0.84.1` |
| vendored at | *(not yet — see docs/roadmap.md phase 3)* |

Our extensions in `pi-ext/` target this version's extension API. pi is not
forked; it is pinned and redistributed as-is.

### bun (the runtime)

| | |
|---|---|
| upstream | https://bun.sh |
| pinned version | `1.3.14` |
| why | pi is a Node/TS program; bun runs `dist/cli.js` directly (verified) and is a single static binary, so the tarball needs no system Node |
| which build | `bun-linux-x64-**baseline**.zip`. The default build needs AVX2 and dies with `Illegal instruction` on a plain KVM guest — measured under `qemu-x86_64 -cpu Nehalem`, where baseline prints its version and the default one crashes. |

pi upstream builds its own release binary with `bun build --compile`, so bun is
a supported runtime for it rather than a gamble.