aboutsummaryrefslogtreecommitdiffstats
path: root/sl0ppij/zellij-utils/src/client_server_contract (follow)
Commit message (Collapse)AuthorAge
* sl0p: carry pane and tab purposes over the wireuser2026-08-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `new-tab --layout` / `--layout-string` created the tab and silently dropped every purpose the layout declared -- the tab's own (which rides the tab's root layout) and each pane's. Layouts applied at session creation kept theirs, so this only broke tabs added at runtime, which is exactly what an orchestrator does. Found by integration-testing the sl0ppi CLI against a real session rather than trusting that the documented feature worked on this path. Cause: TiledPaneLayout and FloatingPaneLayout had no protobuf `purpose` field, so anything travelling as an Action lost it. The original workspace-hints commit says as much in a comment -- "adding a proto field would force regenerating the committed assets" -- because generated prost output is checked in and protoc was not available. It is now (a user-local protoc 25.1, no sudo, no system package), so the deferral can be paid off properly instead of worked around. There are two protobuf schemas and the distinction matters: plugin_api/ is what plugins speak, client_server_contract/ is what the CLI speaks. The first attempt fixed only plugin_api and changed nothing observable; both now carry the field. plugin_api/action.proto TiledPaneLayout.purpose = 14 FloatingPaneLayout.purpose = 13 client_server_contract/common_types TiledPaneLayout.purpose = 16 FloatingPaneLayout.purpose = 15 Purposes are sanitised on ingest, so a value arriving over IPC obeys the same invariant as one parsed from a layout file (bounded token, <=64 chars) whoever constructed the message. Verified live: a tab declaring `rm -rf /; echo "x"` is stored as `rm-rf/echox`, and a 200-char pane purpose arrives capped at 64. Tests: two new wire round-trips (a NewTab layout carrying tab, pane and floating purposes; and the sanitiser). zellij-utils 473 passed, zellij-server 1499 passed. Live: `new-tab --layout-string` now reports purpose='project:added/nested' with panes 'agent:main' and 'logs:app'.
* sl0p: --purpose flag and tab-level purposeuser2026-08-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Completes the two pieces deferred from the first workspace-hints pass. `zellij run --purpose X` / `zellij action new-pane --purpose X` tag a pane at spawn time, which is what an agent wants for panes it creates itself; the OSC wrapper still works for programs that declare their own role. Not supported with --in-place, which replaces another pane rather than being a pane of its own: clap rejects the combination rather than accepting a flag that would do nothing. `tab name="work" purpose="agent-work"` gives a whole tab a role, reported by `list-tabs --json`. It rides the tab's ROOT layout node, reusing the pane field because a tab's root is the tab container and never itself a pane -- asserted by a test for the tightest case (a tab holding exactly one pane), since a leak there would silently mislabel a pane. The interesting part is why the flag first shipped broken. There are TWO protobuf boundaries -- the plugin API and the client->server IPC contract -- and a CLI flag must cross the second one. Defaulting the field in the conversion (what "no protoc" usually forces) compiles cleanly and then silently drops the value in transit, so --purpose parsed, printed a pane id, and did nothing. Fixed by adding the field to both contracts by hand, in the .proto AND the committed generated prost, kept in lockstep so a future regeneration reproduces it: protoc is only needed to regenerate, not to build. Both boundaries now have a round-trip test, and the IPC one was confirmed to fail when the wire read is removed. Sanitising moved to Grid::set_authoritative_purpose, the single choke point every out-of-band source passes through, after the CLI path was observed delivering `bad purpose; rm -rf /` intact into list-panes --json.
* vendor(sl0ppij): import zellij v0.45.0 treeuser2026-08-12
Squashed import of upstream zellij at 0e6e4404 ("Support the Kitty Image Protocol (#5428)"), the merge-base our fork was developed against. Upstream's 3311 commits are deliberately NOT replayed here; only our own fork commits are, so the monorepo stays small and `git log sl0ppij/` shows sl0p work, not zellij's entire history. Upstream provenance is tracked in FORKS.md and can always be re-fetched from https://github.com/zellij-org/zellij.