1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
|
# 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 | 2 commits (`sl0p: double-click a tab to rename it`, `sl0p: a new-tab button and margins that match the pane gap`) |
| 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 |
**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 |
pi upstream builds its own release binary with `bun build --compile`, so bun is
a supported runtime for it rather than a gamble.
|
