Files

T

sergio 550c98f275 refactor(monorepo): reorganización lógica + renames + SDDs + split CHANGELOG

Reorganización física de crates/:
- core/ (mezclaba 6 propósitos) se divide en protocol/, init/, runtime/, compat/
- shared/ (3 crates) se redistribuye en protocol/ e init/
- lapaloma (sub-módulo de ui_engine) se promueve a modules/pineal/

Renames de proyectos:
- shipote → shuma (runtime de sandboxes)
- nouser → akasha (explorador de Mónadas)
- yahweh → nahual (motor GPUI, antes ui_engine/)
- lapaloma → pineal (data-viz agnóstica)

Fraccionamiento UI → core agnóstico:
- vista-core (DeckState + snap, 175 LOC, 5 tests verdes)
- barra-core (Task + render_html + sanitize, 90 LOC, 5 tests verdes)
- vista-web y barra-web ahora son thin DOM bindings

Documentación nueva:
- 16 SDDs por subdirectorio (≤80 LOC c/u): protocol/init/runtime/compat
  + 10 módulos + apps/
- docs/STATUS.md con cifras reales por proyecto
- docs/ROADMAP.md con plan a finalización (6 hitos, ~6-8 semanas)
- CHANGELOG.md particionado en docs/changelog/<proyecto>.md (7 buckets)

Automatización:
- scripts/reorg.py — script idempotente que: git mv directorios, renombra
  package names, recomputa path = refs, reescribe imports rust, actualiza
  workspace Cargo.toml. Soporta --dry-run.
- scripts/split-changelog.py — particiona CHANGELOG por componente.

Validación:
- cargo check --workspace pasa (124 crates + 2 nuevos cores).
- 10 tests adicionales (5 en vista-core + 5 en barra-core) verdes.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

2026-05-19 14:48:34 +00:00

3.7 KiB

Raw Blame History

shipote

Runtime de espacios aislados con flujo tipado dentro del fractal brahman.

shipote no es un shell POSIX. Es un daemon long-running que:

Aísla procesos en Workspaces (cada uno con su SomaSpec: namespaces, cgroup, rlimits).
Encadena comandos en Pipelines (DAG con fan-out, fan-in, taps, replay buffer).
Discierne contenido sobre cada flow (detecta application/json, text/markdown, magic bytes, hasta brahman:card).
Expone data plane real: subscribers externos se conectan a Unix sockets y reciben los bytes del stream.
Se integra al ecosistema vía brahman-sidecar (anuncia Cards al broker).

                         ┌─────────────┐
                         │  shipote    │  daemon long-running
                         │  -daemon    │  $XDG_RUNTIME_DIR/shipote.sock
                         └──────┬──────┘
                                │ admin protocol (postcard)
              ┌─────────────────┼─────────────────┐
              │                 │                 │
        ┌─────▼─────┐     ┌─────▼─────┐     ┌─────▼─────┐
        │ shipote   │     │ shipote-  │     │  HTTP /   │
        │  (CLI)    │     │  shell    │     │  custom   │
        │           │     │  (GUI)    │     │  (futuro) │
        └───────────┘     └───────────┘     └───────────┘

Quick start

# 1. Compilar
cargo build -p shipote-daemon -p shipote-cli

# 2. Arrancar daemon (en una terminal):
SHIPOTE_LOG=info ./target/debug/shipote-daemon

# 3. En otra terminal:
./target/debug/shipote health
./target/debug/shipote workspace create demo.toml
./target/debug/shipote run -w <ws-id> /bin/echo -- hola

Estado actual

11 crates en el monorepo. Ver ARCHITECTURE.md.
85 tests pasando.
Compatible con cualquier supervisor (ente-incarnate es reusable — no requiere ser PID 1).

Documentación

ARCHITECTURE.md — qué crates lo componen, cómo se conectan, decisiones clave.
CLI.md — referencia de comandos del binario shipote.
RECIPES.md — specs TOML de workspaces y pipelines con casos prácticos.
DEVELOPMENT.md — cómo correr daemon, GUI, tests, snapshot.

Acoplamiento con el resto del monorepo

Reusa	Propósito
`ente-incarnate` (extraído de `ente-soma` en Fase 0)	clone(2) + namespaces + cgroup + rlimits
`brahman-card`	tipos `Card`, `SomaSpec`, `Flow`, `TypeRef`
`brahman-sidecar` + `brahman-handshake`	anuncio al broker
`ente-snapshot` filosofía	persistencia (shipote tiene su propio `ShipoteSnapshot` v4)
`yahweh-launcher` + widgets	GUI `shipote-shell`
`shipote-discern` ← usado por	`yahweh-provider-fs` (mime per archivo) y `nouser-core::cluster::pick_lens`

Limitaciones declaradas

mount/pid/net/uts/ipc/cgroup namespaces requieren CAP_SYS_ADMIN o combo con CLONE_NEWUSER.
user namespace puede estar bloqueado por sysctl o LSM (apparmor/selinux).
cgroup v2 limits (memory.max, pids.max) requieren delegation. Sin delegation, accounting funciona pero el kernel no enforce.
Pipeline restart preserva spec pero no ULIDs del pipeline_id (cada relaunch genera uno nuevo).
Replay buffer broadcast: subscribers tarde reciben el snapshot del replay (cap configurable por bytes o chunks), pero pueden perder chunks intermedios si el ring rota antes de conectarse.

3.7 KiB Raw Blame History

shipote

Quick start

Estado actual

Documentación

Acoplamiento con el resto del monorepo

Limitaciones declaradas

3.7 KiB

Raw Blame History