aboutsummaryrefslogtreecommitdiffstats
path: root/cli/src/core/sl0ppij.ts (follow)
Commit message (Collapse)AuthorAge
* cli: survive a dead session, and a flaky terminaluser2026-08-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Three bugs found on a fresh Debian box, all of which made sl0ppi look broken when the terminal underneath it was the problem. 1. JSON crash on startup. `action list-panes --json` against a session that has died exits 0 with EMPTY stdout, and JSON.parse("") threw "JSON Parse error: Unexpected EOF" at the user. Empty output is now "nothing", and genuinely malformed output is reported with the command name and the offending text. 2. `up` silently resurrected. A dead-but-resurrectable session is not an empty slot: `attach --create-background NAME` restores it from the serialised copy and IGNORES --layout. The result was a root full of projects coming back as plain shells with no agents and no purposes -- and the resurrected background session then exited again within seconds. sl0ppi now refuses to guess and explains the two real options (`up --fresh` to rebuild, `sl0ppij attach` to restore it properly in a terminal). Verified on a clean slate that a fresh `up` produces exactly the right panes: purpose='agent:main' held=true cmd='pi'. 3. The terminal's CLI actions are racy. Measured against a LIVE session on a 2-vCPU box: list-tabs and list-panes each fail ~60% of the time while the session is detached, ~25% with a client attached, either with empty output or "There is no active session!" (the action client consults get_active_session() before it looks at -s). That is a defect in sl0ppij -- filed as a known issue -- but these are idempotent reads, so sl0ppi retries them with backoff and distinguishes "the session is gone" from "the terminal would not answer". `sl0ppi ls` went from failing most runs to 8/8. Also: - session creation returns before the server is registered, so `up` now waits for readiness instead of racing its own next command - UserError: actionable answers ("no project foo", "that session is a saved dead copy") print and exit 1 instead of falling through to sl0ppij, which buried the explanation and started a session nobody asked for - `sl0ppi print <project>` implemented; it was referenced by the init template and the design doc but did not exist
* cli: up, ls, open, closeuser2026-08-12
Slice 2 of docs/cli-design.md. The commands read the world (discovery + list-tabs), compute a plan, then apply it -- never mutating while walking, which is how `up` stays idempotent. sl0ppij.ts process wrapper; every piece of state comes back out of list-tabs/list-panes, so there is nothing to desync layout.ts composes the tab node around a project's fragment root.ts root resolution, session naming, the root registry workspace.ts up / ls / open / close index.ts dispatch + the fail-open wrapper Four things this turned up that reading the code would not have: - `attach --create-background` fails with "There is no active session!" when the caller is itself inside a session -- which sl0ppi almost always is, being run from the user's daily-driver terminal. Session creation now runs with the SL0PPIJ*/ZELLIJ* markers stripped: we are creating a new detached session, not nesting. - falling open by passing our own argv to sl0ppij just produces "unrecognized subcommand: up" and still leaves the user without a terminal. Our verbs and flags are stripped first, so what is handed over is something sl0ppij actually understands. - attaching panics in the client when stdin is not a tty, so `up` from a script or CI step died. It now reports the session is ready and exits. - a start_suspended pane reports `is_held`, not `exited`. Conflating them made `ls` claim every agent was running when none had started. Plugin panes (the status bar, the link handler) also inflated pane counts and are now excluded as chrome. Index conventions were verified against a live session rather than inferred, because guessing closes the wrong tab: list-tabs `position` and `close-tab --tab-id` are 0-based, `go-to-tab` is 1-based, and closing renumbers every tab after it, so batched closes run in descending position order. Verified end to end against a real session (three projects, one shipping a custom fragment): up creates the session with all tabs and their purposes; up again reports "up to date" with tabs unchanged; ls reports panes and agent:suspended correctly; open creates-and-focuses and resolves unique prefixes; close removes a tab; deleting a project auto-closes its tab; and with the root itself missing, nothing is closed at all. 64 tests green.