Crate shep 

shep-cli: clap command surface, output rendering, and the daemon launch/re-exec path behind the shep binary. Module-by-module design: docs/systematic-refactor/refactor-workspace/map.md.

The crate’s whole public API is three entry points — main, main_runtime, main_dev — each returning std::process::ExitCode for the binary that calls it. Every other item is private. Embedding shep in another program is shep-client’s job, not this crate’s: that crate is the published embedding API, re-exports shep-core, and carries none of the process-ownership assumptions (a clap tree that is #[cfg(unix)] in half its dispatch, an exit code it expects to own) this one does.

serve, runtime, and dev (spec docs/specs/shep-v1.md §9): a hand-rolled static file server (no axum, no tower-http; the maintainer’s ruling — the ledger has the reasoning), a foreground no-daemon container mode with a PID-1 init split for zombie reaping, and an isolated foreground development flock. Three [[bin]] targets sit over this library: shep itself, plus shep-runtime and shep-dev, the two container-entrypoint aliases that prepend their verb before parsing (see main_runtime/main_dev). The ratatui lookout dashboard has all four panes — the flock table and shell, the bleats feed, the sheep detail pane, and the host-usage strip — a name filter that narrows the table in place, lambs in the detail pane, and the three action keys (x stop, R restart, L reload) behind the --allow-control gate, each arming a confirm rather than acting on the keypress that pressed it. Remaining workspace debt, none of it here: docs/specs/deferred.md.

Functions

main

The shep entry point. Parses this process’s arguments and runs one verb.

main_dev

The shep-dev entry point: shep dev, with the verb supplied.

main_runtime

The shep-runtime entry point: shep runtime, with the verb supplied.