1# modules/shuma/ — Runtime de espacios aislados (era shipote)
2
3**Propósito.** Cada Workspace = un proceso aislado (namespaces +
4cgroups + capabilities filtradas) que expone un wire protocol tipado.
5El daemon es dueño de los workspaces; los clientes (cli/shell/gateway)
6hablan postcard sobre Unix socket.
7
8## Crates
9
10| crate             | tipo | rol                                                     |
11| ----------------- | ---- | ------------------------------------------------------- |
12| `shuma-card`      | lib  | Card del daemon + spec del Workspace                    |
13| `shuma-protocol`  | lib  | Wire types: requests/responses + framing                |
14| `shuma-discern`   | lib  | Lookup de daemon vía broker brahman                     |
15| `shuma-core`      | lib  | Pipeline: parse spec → encarnar → supervisar → persist  |
16| `shuma-intent`    | lib  | Intenciones, grafo de sesión y libro de macros          |
17| `shuma-line`      | lib  | Análisis de la línea de comandos: lexer bash, clasificación, pipeline, autocompletado, `LineState` editable — agnóstico (GUI/TUI) |
18| `shuma-session`   | lib  | `WorkSession`: cwd (= identificador de aislamiento), historial de comandos y grupos reutilizables |
19| `shuma-exec`      | lib  | Ejecución de comandos con salida en streaming (stdout/stderr línea a línea por canal) + `kill` |
20| `shuma-infer`     | lib  | Motor de inferencia: detecta patrones de comandos repetidos en el historial y abstrae sus argumentos variables |
21| `shuma-sysmon`    | lib  | Muestreo de CPU/memoria con historial para los monitores |
22| `shuma-shell-render` | lib | Layout del lienzo de intenciones (legado del grafo)    |
23
24App: `apps/shuma-shell` — el shell GPUI: input inteligente (`shuma-line`),
25ejecución real con streams (`shuma-exec`) volcada al panel central,
26sesión de trabajo con cwd/aislamiento (`shuma-session`), monitores con
27curva (`shuma-sysmon`) y divisores arrastrables. Los crates son
28agnósticos → un futuro `shuma-shell-tui` los reusaría sin cambios.
29
30## sandokan vs. shuma-exec
31
32`sandokan` orquesta *Cards* de brahman (entidades aisladas y
33supervisadas) y es **poll-based por diseño**. El shell ejecuta líneas de
34shell ad-hoc y necesita ver la salida fluir → eso es `shuma-exec`. Dos
35capas distintas, a propósito; un comando que lance un módulo brahman
36podría enrutarse por sandokan más adelante.
37
38## Dependencias
39
40- `shuma-core` ← `init/ente-incarnate` (encarnación real).
41- `shuma-protocol` ← `protocol/brahman-card`.
42- Apps: `shuma-daemon` (dueño), `shuma-cli`, `shuma-shell` (GUI),
43  `shuma-gateway` (HTTP/JSON ↔ postcard).
44
45## Docs
46
47Documentación completa en `crates/modules/shuma/docs/`:
48- `ARCHITECTURE.md` — diseño + flow
49- `CLI.md` — referencia del cli
50- `DEVELOPMENT.md` — guía de contribución
51- `RECIPES.md` — specs ejemplo de Workspace
52
53## Estado
54
55LOC 6,907. Backend completo (daemon + cli funcionales). Tests sobre
56discern + protocol. 14 TODOs en core (supervisión avanzada). Ver
57`docs/changelog/shuma.md`.