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>
This commit is contained in:
sergio
2026-05-19 14:48:34 +00:00
parent 86fb6ae20b
commit 550c98f275
375 changed files with 8512 additions and 7155 deletions
+723
View File
@@ -0,0 +1,723 @@
# Changelog — akasha
Explorador semántico de Mónadas. Renombrado de `nouser` el 2026-05-19.
### feat(nouser-explorer): integración al stack yahweh themed
Iter 10. `nouser-explorer` (la app paralela a `nakui-explorer`
para ver Mónadas via daemon nouser) tenía colors hardcoded
idénticos al patrón previo. Aplico el mismo refactor que se hizo
para `nakui-explorer` en iter 4: instala el theme global, migra
chrome a slots, usa los widgets `banner_themed` / `card_themed` /
`theme_switcher`.
Cambios en `nouser-explorer`:
- **Nuevas deps**: `yahweh-theme`, `yahweh-widget-banner`,
`yahweh-widget-card`, `yahweh-widget-theme-switcher`.
- **`main()`**: `Theme::install_default(cx)` antes de
`cx.open_window`.
- **`render`**: 4 vars `let X = rgb(...)` (chrome) → theme slots
(`bg_app`/`fg_text`/`fg_muted`/`bg_panel`/`border`).
- **Header**: gana flex_row + theme switcher en la derecha (mismo
pattern que nakui-explorer).
- **`error_banner`**: pasa de div hardcoded a `banner_themed(cx,
Banner::Error, ...)` con override de padding (16/8) por
convención del header.
- **2 cards de Engine y Monad**: pasan de `div().flex().flex_col()
.p().mb().bg(card_bg).rounded().border_l_4().border_color()...`
a `card_themed(cx).border_l_4().border_color(accent)...`.
- **Acentos semánticos**: `accent_engine` (cyan, las "máquinas")
y `accent_data` (purple, las Mónadas) quedan locales — son
señales del dominio nouser, no del chrome.
Tests: workspace stack intacto. nouser-explorer no tiene tests
propios (siempre fue una vista live del daemon, sin lógica
testable separada).
Beneficio operativo: las dos apps explorer del repo
(`nakui-explorer` para event log + `nouser-explorer` para Mónadas)
ahora comparten la misma paleta themed + el mismo control de
switcher. Si un usuario las corre lado a lado, la consistencia
visual emerge sola.
### feat(nous-real): cache de embeddings + write-through al CAS de arje
Cierra el ciclo de la crítica del usuario: "Si un archivo no ha
cambiado su hash en el CAS, Nouser ni siquiera debería pedirle al
LLM que re-genere el embedding". El modelo real
(`fastembed-allMiniLML6V2-384d`, ~1-50ms por archivo) era invocado
ciegamente en cada re-cluster del watcher. Ahora se cachea por
`sha256(bytes-vistos) + model_id`.
Pipeline en `handle_file`:
1. Lee primeros 8 KiB (igual que antes).
2. `file_sha = ente_cas::sha256_of(buf)` — hash de los bytes que el
modelo *realmente* verá (no del archivo completo). Garantiza
que un archivo creciendo más allá de la ventana sin tocar la
cabeza siga sirviendo cache hits.
3. Cache lookup: HIT → respuesta en ~µs.
4. MISS → `ente_cas::store(&buf)` (write-through al CAS de arje,
no-fatal si falla) → `backend.embed_one(text)` → `cache.put(...)`.
Backend de cache: sled local en
`$XDG_CACHE_HOME/brahman/nouser-nous-real-embed-cache.sled`. Tree
versionado `embed_cache_v1`; el `MODEL_ID` viaja en la key, así que
cambiar de modelo invalida el cache implícitamente. Override por env
`NOUSER_NOUS_REAL_CACHE`.
Encoding compacto: cada `Vec<f32>` se serializa como bytes
little-endian (4B por f32, sin overhead). Para el modelo default
(384-d) son 1.5 KiB por entry. Decode tolera bytes corruptos
(longitud no-múltiplo de 4 → `None`, no panic).
Por qué sled y no `ente-cas` directo: el CAS de arje es flat
sha256-keyed; la cache necesita un mapeo `(file_sha, model_id) →
embedding`, no expresable como entry CAS. El write-through a CAS
queda como registro consultable + futura GC.
API:
- `EmbedCache::open()` → abre sled, idempotente.
- `EmbedCache::open_at(dir)` para tests.
- `EmbedCache::get(sha, model)` → `Option<Vec<f32>>`.
- `EmbedCache::put(sha, model, &[f32])` → no-fatal en error.
- `EmbedCache::len()` → contador para logs (best-effort).
Mock NO se modifica — su embedding pseudo-32d es metadata-hashing
puro, sin costo. Cachearlo sería overhead.
Tests: 5 unitarios (`roundtrip_returns_same_vector`, `miss_returns_none`,
`different_models_do_not_collide`, `different_content_different_keys`,
`corrupted_value_returns_none`). Verdes con `--features embeddings`;
stub mode (sin feature) sigue compilando sin tocar cache.
### feat(nouser+sidecar): watcher con debounce + re-publish al broker
Cierra las dos limitaciones del watcher previo: ya no spamea N veces por
una sola edición, y el broker ve los cambios estructurales en lugar de
quedarse con manifests congelados al arranque.
$ nouser daemon /tmp/x &
$ touch /tmp/x/src/a.rs /tmp/x/src/b.rs /tmp/x/src/c.rs
# daemon log (un solo batch, no 9 reacciones):
[watcher] ⚙ batch: 6 path(s) coalescidos → re-scan
[watcher] ✦ x/src nace (3 miembros, lens=Code)
[watcher] ⌃ delta: 1 nuevas, 0 refrescadas, 0 cerradas — 3 sesiones vivas
Mecánica del debounce (150ms):
- `spawn_fs_watcher` arma dos threads: **dispatcher** filtra eventos
notify Create/Modify/Remove a un canal de paths; **coordinator**
mantiene `HashMap<PathBuf, Instant>` y dispara batch sólo cuando
todos los paths llevan ≥150ms quietos.
- Un `:w` típico de vim (~5 eventos por archivo) colapsa a 1 batch.
Mecánica del re-publish:
- `SidecarPool` ahora trackea `HashMap<Ulid, AbortHandle>` indexado
por `Card.id`. Llamar `pool.spawn(card)` con un id ya presente
aborta la sesión previa y abre una nueva — `spawn` se vuelve
idempotente: re-publicar una Mónada cuya composición cambió
refresca su sesión en el broker sin dejar zombies.
- Nueva API `pool.drop_session(id)` para cerrar una sesión
explícitamente cuando una Mónada desaparece (directorio quedó
bajo `min_files` o se borró).
- `pool.live_sessions()` para introspección/logs.
- `process_change_batch` re-scanea + re-clusteriza con hidratación,
diffea contra prior_monads, y para cada Mónada decide:
- removida → `drop_session`
- nueva → `spawn` con ✦
- composición cambió (members o centroid distintos) → `spawn` con ↻
- idéntica → no-op
Trade-off aceptado: re-scan global por batch (no incremental). Es
O(N archivos) por evento y para árboles típicos (<10k) cae en
<100ms. Optimizar a re-cluster parcial cuando duela.
Tests: workspace completo verde.
### feat(nouser): notify watcher — el sistema reacciona en tiempo real
El daemon ahora monta un `notify::recommended_watcher` recursivo
sobre el directorio. Cada `Create`/`Modify` de archivo regular
dispara: embedding del archivo, filtro por `centroid_model`, ranking
contra centroides existentes, log con marker 🧲 / · según supere
el umbral de atracción.
$ nouser daemon /tmp/x &
# en otra terminal:
$ vim /tmp/x/src/nuevo.rs
# daemon log:
[watcher] 🧲 /tmp/x/src/nuevo.rs → x/src (0.7470)
$ echo "edit" >> /tmp/x/docs/n1.md
[watcher] 🧲 /tmp/x/docs/n1.md → x/docs (0.8169)
Mecánica:
- DB pasa a `Arc<Mutex<MonadDb>>` para sharing con el thread del
watcher.
- Watcher en thread dedicado (`nouser-watcher`); reacciona sólo a
Create/Modify, ignora Access/Metadata-only.
- `react_to_change(path, metadata, db)` computa embedding,
filtra por `centroid_model`, busca best attraction.
- No re-publica al broker ni muta DB — sólo observa y narra. La
invalidación selectiva (re-cluster + replace_monads + diff
publish) queda como work futuro.
Limitación conocida: `notify` emite múltiples eventos por una sola
edición (Create + Modify, etc.). Sin debounce, el watcher reporta
varias veces. Aceptable para demo; production conviene debounce
~100ms por path.
Tests: 7 (card) + 24 (core) verdes, 0 errores, 0 warnings.
### feat(nouser): hidratación del daemon vía sled + path_hint
El daemon ya no recomputa ciegamente al arrancar. Si la DB tiene
Mónadas previas con `centroid_model` válido, las publica instantáneo
y el re-scan reusa sus IDs vía `path_hint`.
Schema:
- `MonadManifest.path_hint: Option<String>` — identidad estable
derivada del origen (para `by_directory`, el parent dir
canónico). Permite reusar ULID across re-scans.
Algoritmo (cluster):
- Nueva fn `cluster::by_directory_hydrated(files, min_files,
prior: Option<&MonadDb>)`. Cuando hay `prior`, busca Mónada con
mismo `path_hint` Y mismo `centroid_model`; si la encuentra,
reusa `id`, `lineage` y `created_at_ms`.
- `by_directory` queda como wrapper sin hidratación (back-compat).
Daemon (cmd_daemon):
1. Open sled si NOUSER_DB_PATH existe.
2. Publica las Mónadas previas con `centroid_model` válido (las
inválidas se descartan con log explícito).
3. Re-scan + `by_directory_hydrated(prior=&db)`.
4. Sólo spawnea sidecars para Mónadas con id que NO estaba en la
hidratación inicial. Los path_hints existentes preservan identidad,
evitando duplicados en el broker.
5. Persiste el set actualizado.
Validación end-to-end:
$ NOUSER_DB_PATH=/tmp/h.sled nouser daemon crates/core
# arranque 1: DB vacía
re-scan 102 archivos → 5 mónadas
1 ente + 5 mónadas vivas (5 nuevas vs hidratación)
$ NOUSER_DB_PATH=/tmp/h.sled nouser daemon crates/core
# arranque 2: DB poblada
hidratadas 5 mónadas previas en O(1)
re-scan 102 archivos → 5 mónadas
1 ente + 5 mónadas vivas (0 nuevas vs hidratación)
Costo del arranque 2: ~0.06s user CPU. Antes (sin hidratación) era
re-scan + cluster + spawn x N — segundos enteros para árboles grandes.
Tests: 7 (card) + 24 (core) verdes.
### feat(nouser): centroid_model — versionado de embeddings
Protege contra el bug silencioso de mezclar centroides de modelos
distintos (mock 32-d vs real 384-d), que daba scores sin sentido.
- `MonadManifest.centroid_model: Option<String>` taggea qué modelo
produjo el `centroid`. `None` = legacy pre-versioning.
- `nouser_core::embed::MODEL_ID = "nouser-pseudo-32d"`. El cluster lo
setea en cada Mónada que genera.
- `nouser-nous-mock` reusa la misma constante (`use
nouser_core::embed::MODEL_ID`); produce vectores idénticos al
cluster local, así que reportar el mismo ID es honesto.
- `nouser-nous-real` reporta `"real-fastembed-allMiniLML6V2-384d"`
(dim distinta, semántica distinta).
- `cmd_attract` ahora:
- Captura el `model_id` del embedding del target (local o remote).
- Filtra Mónadas cuyo `centroid_model` no matchee.
- Reporta `embed: <source> (<model>)` y `skipped: N mónadas con
centroid_model distinto` cuando descarta.
Resultado operativo: cambiar de mock a real (vía
`BRAHMAN_BROKER_CONTEXT=prod`) hace que `attract` filtre las Mónadas
viejas con cero score en lugar de fingir que las puede comparar.
## 2026-05-08
### chore: profile.dev slim — target/ ~50% más liviano
Cambios en `[profile.dev]` raíz para que builds futuras no desborden
disco. Decisiones:
- `debug = "line-tables-only"`: stack traces correctos, drop del resto
de symbols. Sin pérdida real para nuestro flujo.
- `split-debuginfo = "unpacked"`: relink más rápido, debuginfo en
archivos aparte.
- `codegen-units = 256`: paralelismo + builds incrementales chicas.
- Override `[profile.dev.package.X]` para los pesados (gpui, ort,
fastembed, tokenizers, image): `opt-level = 1`, `debug = false`.
No los debuggeamos línea por línea, no necesitan info pesada.
Resultado: binarios ~3× más livianos. ente-zero 125→47 MB; mock-nous
~50→22 MB.
### feat(nouser): dynamic binding — consumer descubre el provider vía broker
Cierra el bucle prometido por `priority_contexts`: el cliente ya no
hardcodea el socket del provider de embeddings. En su lugar:
1. Si `NOUSER_NOUS_SOCKET` está set, lo usa directo (atajo explícito).
2. Si no, abre `brahman_handshake::client::Client` al `brahman-init`,
anuncia un consumer Card mínimo con `flow.input = embed-result:json`,
espera 3s por el primer `MatchEvent::Available`, y usa el
`producer_service_socket` que viaja en el evento.
Esto activa el swap automático mock↔real:
- `BRAHMAN_BROKER_CONTEXT=test`: el bias `+1 en test` del mock lo hace
ganar; consumer recibe el socket del mock.
- `BRAHMAN_BROKER_CONTEXT=prod`: el bias del real lo hace ganar.
- Sin contexto: empate alfabético entre los presentes.
Validación end-to-end:
$ ente-zero & nouser-nous-mock &
$ # Sin NOUSER_NOUS_SOCKET:
$ nouser attract --remote crates/core archivo.rs
embed: remote
🧲 0.9058 ente-brain/src ...
(mock log confirma "embed_file path=...")
Cambios:
- `nouser-core` Cargo.toml: deps directas brahman-handshake + tokio.
- `cmd_attract` resuelve el socket por discovery antes de llamar a
`embed_via(&path, file)` (mini-runtime tokio current_thread inline).
Bug que se descubrió en el camino: la "flakiness" reportada de
`cargo test --workspace` era disco lleno (24 GB en `target/`), no
condición de carrera. Con `cargo clean` + profile slim, todos los
tests pasan deterministas.
### feat(nouser): yahweh widget — `nouser-explorer` panel GPUI
Bin GPUI standalone que consulta `brahman-admin` cada 2s y renderea
todas las sesiones del Init como cards. Cierra el círculo visual del
ecosistema brahman.
- Crate nuevo `crates/apps/nouser-explorer` (deps: brahman-admin,
brahman-card, gpui).
- Ventana 900×640 con header del estado del Init, banner de error
cuando no conecta, y lista de cards (una por sesión).
- Cada card muestra: kind + label + lifecycle, ULID corto, summary
(si data), keywords, lens hint, service_socket si está, y refs
(RelationshipKind → target_label). El borde izquierdo coloreado
diferencia ente (azul) de data (lavanda).
- `cx.spawn(async move |this, cx| { … })` corre el loop de refresh
en el GPUI executor; `query_blocking` se usa porque GPUI no provee
un runtime tokio.
- Nuevo helper en brahman-admin: `client::query_blocking(path)` —
versión sync de `query()`, para callers con su propio executor.
Uso:
$ ente-zero & nouser daemon crates/core &
$ cargo run -p nouser-explorer
# ventana muestra ~6 cards en vivo, refrescando cada 2s.
cargo check --workspace: 0 errores, 0 warnings.
### feat(nouser): persistencia sled write-through del MonadDb
`MonadDb` ahora soporta backend dual:
- `MonadDb::new()` → memoria pura (default, back-compat).
- `MonadDb::open(path)` → sled-backed con cache en memoria. Carga
contenido existente al abrir; cada `insert_*` hace write-through
(cache + sled).
Diseño:
- 2 trees sled: `files` y `monads`.
- Wire format: serde_json (ergonomía + inspectability con sled-cli;
los manifests son chicos, JSON gana sobre postcard aquí).
- Reads SIEMPRE desde la cache — sled se consulta sólo al abrir.
- `replace_monads()` purga el tree de sled antes de escribir.
Bin nouser: nueva env var `NOUSER_DB_PATH`. Si está set, persiste
en esa ruta; si no, in-memory:
$ NOUSER_DB_PATH=/tmp/monads.sled nouser scan crates/core
scan: 102 archivos en crates/core, 5 mónadas
$ ls /tmp/monads.sled
blobs conf
$ NOUSER_DB_PATH=/tmp/monads.sled nouser scan crates/core
# segunda corrida re-escribe la DB con el nuevo scan
Tests nuevos en db.rs:
- `persistence_roundtrip` — escribe, cierra, reabre, datos están.
- `replace_monads_purges_persistent_tree` — replace limpia el tree.
24 tests en nouser-core (era 22, +2).
### refactor(nouser): labels de Mónada con 2 componentes del path
Resuelve la fricción visual de monorepos donde múltiples Mónadas se
llamaban "src". Nueva función `label_from_path` toma los últimos hasta
2 componentes normales del path y los une con `/`.
$ nouser scan crates/core
[01K..] brahman-admin/src card=5
[01K..] brahman-handshake/src card=6
[01K..] ente-brain/src card=11
[01K..] ente-kernel/src card=4
...
Tests añadidos: `label_from_root_only_one_component`,
`label_from_deep_path_takes_last_two`. Tests existentes actualizados
con los nuevos labels.
### feat(nouser): Phase D-2 — proveedor Nous real (LLM) detrás de feature flag
Cierra el ciclo del módulo Nous: existe un proveedor que produce
embeddings reales con un modelo LLM, mientras que `cargo build` sin
features sigue siendo liviano (no descarga ni compila ML deps).
Crate nuevo:
- `crates/modules/nouser/nous-real`: bin con dos modos según feature.
- **Sin feature (default)**: stub. Bin compila en ~10s, arranca,
sidecarea a brahman-init declarando la Card de real-nous, escucha
en el socket Nous, y rechaza toda request con `ErrorResponse {
error: "compilado sin la feature embeddings. Rebuild con
cargo build -p nouser-nous-real --features embeddings" }`.
`cargo build --workspace` sigue siendo limpio.
- **Con `--features embeddings`**: pulls `fastembed = "4"`. Ese crate
arrastra `ort 2.0.0-rc.9` (ONNX Runtime con binarios descargados
por Cargo) + `tokenizers 0.21` + ~30 deps más. Compila en ~50s.
Modelo default: `all-MiniLM-L6-v2` (384-d, descargado a
`~/.cache/fastembed` la primera vez).
- `EmbedText`: pasa el texto al modelo, devuelve vector 384-d.
- `EmbedFile`: lee primeros 8KiB con UTF-8 lossy, embed como texto.
Para binarios el resultado no es semánticamente útil — caller
decide.
- `Ping`: devuelve `model_id` y `embed_dim` reales.
- Card de real-nous:
- label `nouser.nous_real` (distinto del mock para coexistir).
- `priority_contexts.prod = { priority_offset: +1 }`. En contexto
prod gana sobre el mock; en `test` el mock gana por su propio
`+1`. Sin contexto activo, empate alfabético entre ambos.
Validación end-to-end con modelo real:
$ cargo build -p nouser-nous-real --features embeddings # ~50s
$ ente-zero & nouser-nous-real &
$ # probe vía python al socket Unix:
$ echo '{"kind":"embed_text","payload":{"text":"hello brahman"}}' \
| python3 -c "..." | head
model: real-fastembed-allMiniLML6V2-384d
elapsed_ms: 8
embed_dim: 384
first 5 values: [0.0034, -0.0036, 0.0078, -0.0218, -0.0162]
Tradeoff conocido: las dimensiones del mock (32-d) y real (384-d) son
incompatibles. Cambiar de proveedor invalida los centroides cacheados
de Mónadas. Documentar como "limpiar DB al cambiar proveedor".
Workspace state:
- cargo build --workspace sigue limpio sin features (no ML).
- cargo build -p nouser-nous-real --features embeddings funciona.
- 0 errores, 0 warnings en ambos modos.
Pendientes para D-3 / futuro:
- Discovery de socket: hoy el consumer hardcodea NOUSER_NOUS_SOCKET.
Para que el broker brahman elija real vs mock per-contexto, falta
inyectar el socket del provider electo en el MatchEvent o exponer
un broker query "dame el socket de la sesión X".
- Coexistencia: hoy los dos providers compiten por el mismo socket
path por default. Habría que parametrizarlos a sockets distintos
cuando coexistan.
### feat(nouser): Phase D — proveedor Nous mock + cliente remoto
Cierra el patrón "Nous como módulo aparte intercambiable": el contrato
del proveedor de embeddings vive en su crate, el mock determinístico
implementa ese contrato sirviéndolo por Unix socket, y `nouser-core`
sabe consumirlo remotamente. El switch entre mock y real (futuro) se
hará vía priority_contexts en el broker.
Crates nuevos:
- `crates/modules/nouser/nous`: contrato compartido. Tipos
`EmbedRequest`, `RequestKind { EmbedFile, EmbedText, Ping }`,
`EmbedFilePayload`, `EmbedTextPayload`, `EmbedResponse`,
`PingResponse`, `ErrorResponse`. Wire format: line-delimited JSON
por Unix socket, single-shot per conexión. Constants para los nombres
de flow (`embed-request`/`embed-result`) y el tipo (`json`). Helper
`transport::default_socket_path()` con env var
`NOUSER_NOUS_SOCKET`.
- `crates/modules/nouser/nous-mock`: bin `nouser-nous-mock`. Sidecarea
a brahman-init con Card kind=Ente declarando los flows
`embed-request:json`/`embed-result:json` y un
`priority_contexts.test = { priority_offset: +1 }` (gana sobre
cualquier real-nous en contexto test). Bind del socket Nous, accept
loop, despacha por `RequestKind`. EmbedFile usa
`nouser_core::embed::embed` (los pseudo-embeddings de Phase C).
Modelo: `mock-pseudo-32d`.
Cambios:
- `nouser-core`: dep nueva `nouser-nous`. Subcomando `attract` ahora
acepta `--remote` que abre un socket UnixStream blocking, envía un
`EmbedRequest` y lee la response. Imprime `embed: local|remote`
para que se vea cuál ruta corrió.
Validación end-to-end (un solo terminal, varios procesos):
$ ente-zero &
$ nouser-nous-mock &
$ NOUSER_MIN_FILES=5 nouser daemon crates/core &
$ brahman-status
Sessions (7):
[ente] nouser.nous_mock flows: embed-request, embed-result
[ente] brahman.nouser_engine
[data] src summary: 6 archivos en crates/core/brahman-handshake/src
[data] graph summary: 7 archivos en crates/core/ente-zero/src/graph
...
$ nouser attract --remote crates/core <archivo.rs>
embed: remote
🧲 0.9058 src ...
Mock log: "embed_file path=crates/modules/nouser/core/src/embed.rs"
Bug encontrado y corregido en el camino:
- `ContextBias` tenía `#[serde(skip_serializing_if = ...)]` en sus
campos. Postcard NO soporta skip-condicional (formato no
self-describing): el serializer omitía bytes que el deserializer
esperaba, rompiendo la wire de cualquier Card con
`priority_contexts` poblada.
- Fix: removidos los `skip_serializing_if` de `ContextBias`. JSON
pretty ahora emite `{"pin_to": null, "priority_offset": 0}` en lugar
de objeto vacío. Trade-off aceptado por compatibilidad de wire.
- Test nuevo en brahman-card: `wirecard_postcard_with_priority_contexts`
que ejercita el roundtrip completo postcard.
Tests acumulados: 75 (card 12 +1 nuevo, broker 15, handshake 9,
card-wit 4, admin 0, nouser-card 7, nouser-core 20, nouser-nous 2).
cargo check --workspace: 0 errores, 0 warnings.
Próximo natural: Phase D-2 — `real-nous` con un modelo ONNX/Llama de
text-embedding. La infraestructura ya está lista: declara la misma
Card con `priority_contexts.prod = { priority_offset: +1 }` y el
swap es transparente para el consumer.
### feat(nouser): Phase C — pseudo-embeddings + atracción por centroide
El "imán semántico" matemático del diseño Kairos, sin LLM. Cada
archivo se proyecta a un vector 32-d derivado de sus metadatos; cada
Mónada calcula su centroide; archivos nuevos se asignan por cosine
similarity contra los centroides existentes.
Cambios:
- nouser-core dep nueva: `blake3` (hash determinista de strings).
- `crates/modules/nouser/core/src/embed.rs`:
- `EMBED_DIM = 32`. Estructura del vector:
- dims 0..8: blake3(extension) → identidad de tipo
- dims 8..16: blake3(parent_dir) → identidad de contenedor
- dims 16..24: blake3(file_stem) → identidad léxica
- dims 24..28: tamaño (log + flags)
- dims 28..32: mtime (escala día + cíclicas)
- **Tip clave**: bytes del hash se centran a `[-1, 1]` (no `[0, 1]`).
Sin centrar, dos vectores hash random tendrían cosine ~0.75
espuria; centrados, expectativa ≈ 0 entre no-relacionados.
- APIs: `embed`, `cosine_similarity`, `centroid`, `cohesion`,
`attraction_score`, `best_attraction`. `DEFAULT_ATTRACTION_THRESHOLD = 0.7`.
- `cluster::by_directory` ahora computa el centroide de cada Mónada
(promedio de embeddings de los miembros, L2-normalizado) y lo guarda
en `MonadManifest.centroid`. El centroide viaja al brahman-status vía
`DataFacet.centroid` → ahora se ven los Vec<f32> reales por cada Mónada.
- bin nouser nuevo subcomando: `attract <dir> <file>`.
- Escanea el dir, embeda el archivo objetivo, ranking de afinidad
contra todas las Mónadas con centroide.
- Marca 🧲 si la mejor supera el umbral, `·` si es la mejor pero
debajo, espacio en blanco para el resto.
Validación end-to-end:
$ nouser attract crates/core crates/modules/nouser/core/src/embed.rs
ranking de atracción (cosine similarity):
🧲 0.9058 [01K..] src (11 archivos en crates/core/ente-brain/src)
0.8984 [01K..] src (6 archivos en crates/core/brahman-handshake/src)
0.8918 [01K..] src (5 archivos en crates/core/ente-zero/src)
...
$ nouser attract crates/core crates/modules/nouser/core/Cargo.toml
ranking:
0.3427 [01K..] graph (7 archivos en crates/core/ente-zero/src/graph)
...
(mejor score 0.3427 < umbral 0.7000 — el archivo no se 'pega')
Tests: 20 en nouser-core (era 13, +7 de embed). Total acumulado: 73
(card 11, broker 15, handshake codec+tr 2 + integ 7, card-wit 4,
admin 0, nouser-card 7, nouser-core 20, ente-card 0).
cargo check --workspace: 0 errores, 0 warnings.
Próximo: **Phase D** — `nouser-nous`, módulo aparte para LLM real.
Mock-nous determinista (basado en estos pseudo-embeddings) en
`BRAHMAN_BROKER_CONTEXT=test`; real-nous en `prod`. El switch lo hace
el broker via priority_contexts sin tocar nada más.
### feat(nouser): Phase B-2 — daemon que publica Mónadas al Init
Cierra la unificación: el `nouser daemon` se sidecarea como Ente y
publica cada Mónada como su propia sesión Data. Un solo
`brahman-status` muestra procesos y datos en la misma lista, exactamente
como buscaba el diseño.
Cambios:
- `crates/modules/nouser/core/Cargo.toml`: deps nuevas `brahman-card`
y `brahman-sidecar`.
- `crates/modules/nouser/core/src/bin/nouser.rs`: subcomando
`daemon <dir>`.
- Spawna un sidecar para el "engine" (`brahman.nouser_engine`,
kind=Ente) — el ser que produce y administra Mónadas.
- Scan + cluster del dir.
- Para cada Mónada, llama `monad.to_brahman_card()` y spawnea un
sidecar (kind=Data). Cada Mónada es una sesión brahman propia
con su ULID estable.
- Park del thread principal: los sidecars siguen pingueando.
Validación end-to-end:
$ ente-zero &
$ NOUSER_MIN_FILES=5 nouser daemon crates/core &
$ brahman-status
Sessions (6):
[ente] ... brahman.nouser_engine lifecycle=Daemon
[data] ... src summary: 5 archivos en crates/core/brahman-admin/src
members: 5 (dispersion=0.00)
lens hint: code
[data] ... src summary: 11 archivos en crates/core/ente-brain/src
...
[data] ... graph summary: 7 archivos en crates/core/ente-zero/src/graph
El protocolo de presentación es uno solo: la Card. La función — anunciar
identidad, exponer metadata, ser descubierto — es idéntica para procesos
vivos y agrupaciones de datos. La UI lo ve como una lista uniforme.
Costo conocido: cada Mónada consume un thread + tokio runtime
current_thread (legacy del sidecar API). Para muchas Mónadas (>50)
conviene consolidar en un único runtime con N tasks. Defer a Phase B-3.
Pendientes propuestos:
- **B-3**: consolidar todos los sidecars en un único runtime tokio
para no spawnear N threads.
- **C**: pseudo-embeddings + atracción por centroide.
- **D**: módulo `nouser-nous` para LLM, swappable por priority_contexts.
- **Polish**: labels con 2-3 componentes del path.
- **Crossreferencia**: que un Ente pueda anunciar "estoy procesando la
Mónada X" y la Mónada anuncie "Ente Y me está procesando".
cargo check --workspace: 0 errores, 0 warnings.
### feat: Phase B-1 — unificación ontológica de Cards (Ente ↔ Data)
La Card es **el** protocolo de presentación del ecosistema, no sólo de
los procesos. Una Mónada Nouser y un Ente Brahman son ambos "entidades
que se presentan"; el consumidor (UI, broker, admin) discrimina por
`kind` cuando importa, pero todos hablan el mismo idioma.
Cambios:
- `brahman-card`:
- `CardKind { Ente (default), Data }`. Conserva back-compat:
Cards existentes son `Ente` por default.
- `DataFacet { summary, keywords, centroid, member_count, dispersion,
presentation_hint }`. Liviano para el wire — listas grandes
(members, embeddings completos) se consultan al daemon dueño bajo
demanda.
- `Card.kind` y `Card.data: Option<DataFacet>` agregados. WireCard
espeja, conversiones `From` propagan.
- Default impl actualizado.
- `brahman-broker::BrokeredCard`: propaga `kind` y `data` desde la Card
registrada. No afecta el matching (sigue siendo por TypeRef +
priority + pin_to); permite a observadores discriminar sin re-query.
- `nouser-card`: depende ahora de `brahman-card`. Nuevo método
`MonadManifest::to_brahman_card()` que proyecta:
- id, label, lineage → directos.
- payload Virtual, supervision Delegate, lifecycle Daemon (placeholder
semántico — la Mónada no se ejecuta).
- kind = Data.
- data = Some(DataFacet) con summary, keywords, centroide,
member_count, entropy → dispersion, y un `presentation_hint` derivado
del `Lens` (`Code` → `"code"`, `Gallery` → `"gallery"`, etc.).
- Test nuevo: `projects_to_brahman_card`.
- `brahman-status`: cada sesión muestra ahora `[ente]` o `[data]` como
prefijo. Para sesiones `data`, render adicional con summary, members
+ dispersion, keywords y lens hint.
Resultado: la UI (yahweh, brahman-status, futuro explorer) ve una sola
lista uniforme. No tiene que saber si está mirando un proceso o un
cúmulo de datos — sólo lee el Card y se adapta por `kind`.
Tests acumulados: 59 (card 11, broker 15, handshake codec+transport 2 +
integ 7, card-wit 4, admin 0, nouser-card 7, nouser-core 13).
cargo check --workspace: 0 errores, 0 warnings.
Próximo: **Phase B-2** — bin `nouser daemon <dir>` que sidecarea cada
Mónada como una sesión brahman, publicándola al broker. Brahman-status
las verá junto a los entes.
### feat(nouser): Phase A — mecanismo determinista de Mónadas
Primer trozo del módulo Nouser (Kairos): explorador de Mónadas como
"imanes semánticos" sobre el filesystem. Phase A cubre el 90% de los
casos sin tocar IA — sólo metadatos y heurísticas.
Crates nuevos:
- `crates/modules/nouser/card`: `MonadManifest` (la Tarjeta de
Presentación de una Mónada — espejo conceptual de `brahman::Card`
pero para datos, no para procesos runtime). Campos: id (Ulid),
label, summary, centroid (vacío en Phase A), keywords, cardinality,
entropy [0,1], dominant_lens, pins, members, timestamps,
extensions (forward-compat). 6 tests de validación + JSON roundtrip.
- `crates/modules/nouser/core`: pipeline determinista.
- `scanner`: walkdir → `Vec<FileEntry>` con metadatos (path, size,
mtime, extension). Skipea hidden por default. Configurable max
depth y follow_links.
- `cluster::by_directory`: agrupa por parent dir, mínimo 3 archivos
para promover a Mónada (configurable). Calcula keywords (top-N
extensiones por frecuencia + alfabético), elige `Lens` dominante
(Code/Gallery/Markdown/Database/Grid) según extensión más
frecuente, computa entropía de Shannon normalizada [0,1].
- `db`: `MonadDb` en memoria con índices BTreeMap files/monads y
`resolve_members(monad_id)` que filtra IDs huérfanos. Phase B
traerá persistencia.
- bin `nouser`: subcomandos `scan <dir>`, `show <dir> <prefix>`,
`json <dir>`. Env var `NOUSER_MIN_FILES` para tunear el threshold.
- 13 tests (4 scanner + 6 cluster + 3 db).
Demo end-to-end:
$ nouser scan crates
scan: 255 archivos en crates, 19 mónadas (min_files=3)
[01KR4C13] src card=12 ent=0.00 lens=Code
keywords: rs
[01KR4C13] tests card=14 ent=0.00 lens=Code
keywords: rs
[01KR4C13] fixtures card=5 ent=0.00 lens=Grid
keywords: rhai
...
$ nouser show crates 01KR4C
Monad 01KR4C1370DVF6NMTW6SECNXAF
label: src
summary: 4 archivos en crates/modules/nouser/core/src (ext: rs)
cardinality: 4
entropy: 0.0000
lens: Code
members (4):
4132 bytes crates/modules/nouser/core/src/db.rs
...
Pendientes para próximas fases (anotados, no urgentes):
- **Phase B**: bin `nouser daemon` que sidecarea a brahman-init
declarando flows (`scan-request:json` → `monad-update:json`).
- **Phase C**: pseudo-embeddings deterministas (hash de path/ext/size
a 32-d) + atracción por centroide via cosine similarity. Implementa
el "imán" sin LLM.
- **Phase D**: módulo `nouser-nous` aparte para el LLM real
(Llama/ONNX). En `priority_contexts.test` el Init pinea a
`mock-nous` (embeddings determinísticos); en `prod` a `real-nous`.
- **Polish**: labels de Mónada incluir 2-3 componentes del path para
desambiguar `src/` repetidos en monorepo.
Workspace: 0 errores, 0 warnings. Tests acumulados: 58
(card 11, broker 15, handshake codec+transport 2 + integ 7,
card-wit 4, admin 0, nouser-card 6, nouser-core 13).
+78
View File
@@ -0,0 +1,78 @@
# Changelog — init/
Init (PID 1) + encarnación Linux. Antes: `core/ente-{zero,kernel,soma,snapshot}` + `shared/ente-incarnate`.
### feat(ente-zero): wire de Arje con brahman-net (red P2P opcional + identidad persistente)
Cierra el último pendiente del plan de red: Arje ahora puede arrancar
opcionalmente con `BrahmanNet` configurado, persistir su identidad
libp2p entre reboots, y participar en la malla brahman como nodo
público. Sin breaking changes: usuarios actuales (sin env vars) siguen
viendo el comportamiento Unix-only de antes.
Activación por env vars:
- **`BRAHMAN_LISTEN_MULTIADDR`** — si set, activa la red P2P. Ej:
`/ip4/0.0.0.0/tcp/4101` (público), `/ip4/127.0.0.1/tcp/0` (loopback,
port aleatorio). Sin la var, `brahman_net = None` y todo sigue
como antes.
- **`BRAHMAN_KEYPAIR_PATH`** — override del path donde se persiste
la keypair Ed25519 de identidad libp2p del nodo. Defaults sensatos:
- PID 1 (root): `/var/lib/brahman/init-keypair.bin`.
- Dev mode: `$XDG_DATA_HOME/brahman/init-keypair.bin`
`$HOME/.local/share/brahman/init-keypair.bin`
`/tmp/brahman-init-keypair.bin` (último recurso).
- **`BRAHMAN_BOOTSTRAP_PEERS`** — lista coma-separada de multiaddrs
para dial-ear al arranque y entrar al DHT. Sin esto, el nodo
arranca aislado hasta que alguien se conecte a él.
Comportamiento al activarse:
1. `keypair_store::load_or_generate(path)` carga la keypair de disco
o genera+persiste una nueva (32 bytes raw, permisos 0o600,
atomic rename). Reboots conservan el `peer_id`.
2. `BrahmanNet::with_keypair(kp)` arma el swarm con esa identidad.
3. `net.listen(multiaddr)` espera dirección resuelta y la loggea.
4. `BRAHMAN_BOOTSTRAP_PEERS` (si set) → dial a cada multiaddr.
5. El handshake server se levanta con `ServerConfig.net = Some(net)`,
que activa `announce_outputs` automático en el DHT por cada Card
con outputs.
6. Además del Unix accept loop (existing), se monta un libp2p accept
loop sobre el mismo `Server` compartido. Sesiones locales y
remotas conviven en las mismas tablas (sessions, push_table,
broker, last_matches).
Refactor del Unix accept loop: antes consumía el server vía
`server.run().await`; ahora usa `Arc<Server>::accept_one().await` en
loop para coexistir con el libp2p accept loop sin moverse el server.
Degradación grácil en cada paso: si la keypair no carga, si el
multiaddr es inválido, si el listen falla, si el bootstrap dial
revienta — loggeamos y seguimos en modo Unix-only. La doctrina de
PID 1 ("ningún subsistema opcional rompe el bucle primordial") se
mantiene.
Tests: 4 unit en `keypair_store`:
- `generate_persist_and_reload_yields_same_peer_id` — peer_id estable
across reloads (la propiedad fundamental).
- `rejects_corrupted_file` — archivo de tamaño incorrecto rechazado.
- `persisted_file_is_owner_only` — permisos 0o600 verificados.
- `default_path_honors_env``BRAHMAN_KEYPAIR_PATH` override
respeta tanto dev como root mode.
Ente-zero compila clean. Ningún test del workspace regresa.
Lo que esto desbloquea hoy:
- Para activar Arje como nodo público, basta:
```sh
BRAHMAN_LISTEN_MULTIADDR=/ip4/0.0.0.0/tcp/4101 ente-zero
```
- Cualquier consumer (en otra máquina) puede luego dial-ar a ese
multiaddr + descubrir Cards anunciadas via DHT + abrir handshake
remoto firmado.
- La identidad del nodo (su `peer_id`) sobrevive reboots, así que
los nodos remotos pueden cachear "este peer_id es Arje en
máquina X" sin invalidarse cada vez.
Pendientes futuros:
- `stop_providing` al cleanup de sesión (records DHT con TTL ~24h).
- Allowlist/Denylist de peers (PKI explícito).
- Rotación de keypair sin perder peer_id (multi-key identity).
+316
View File
@@ -0,0 +1,316 @@
# Changelog — minga (semantic_dht)
### feat(minga-explorer): listings de items recientes en cada stat card
Iter 12. Hasta ahora minga-explorer mostraba sólo counts (3
números). Ahora cada stat card muestra también un sample de los
items dentro: hashes truncados de los 5 primeros nodos AST
(con su `kind`), atestaciones (`content_hash ← did_short`) y
claves MST. Mucho más útil para debugging que el "tengo N items".
Cambios en `minga-explorer`:
- **`RepoSnapshot` extendido** con 3 nuevos `Vec<...>`:
- `recent_nodes: Vec<(String, String)>``(hash_short, kind)`.
- `recent_attestations: Vec<(String, String)>`
`(content_hash_short, did_short)`.
- `recent_mst_keys: Vec<String>``hash_short`.
- Cap de 5 items por sección via `RECENT_LIMIT` const.
- **`load_snapshot` itera los stores** y toma los primeros 5
items via `iter().filter_map(Result::ok).take(RECENT_LIMIT)`.
Errores per-item se silencian (`filter_map`) — el dashboard
muestra lo que pueda; un par de items corruptos no debería
tirar el panel.
- **`short_hash(&str)` helper local**: trunca un hex a sus
primeros 12 chars (48 bits, distintivo dentro de un repo
single-machine).
- **`stat_card` extendido**: nuevo arg `recent_items: &[String]`.
Si no está vacío, agrega un sub-header `"recent (N de TOTAL):"`
+ una linea por item. Cada line es texto pequeño (`px(11)`)
con el color principal del theme — visualmente queda como
monospace listing aunque no use mono font (no hay todavía
en el theme).
Tests: 2 → **4** (+2 sanity de los nuevos defaults + del
`short_hash`).
Beneficio operativo:
- Después de `minga ingest archivo.rs`, el explorer muestra
inmediatamente los hashes de los nodos AST creados, qué `kind`
tienen, y las atestaciones firmadas — sin necesitar `minga
status` o queries SQL.
- "5 de 247" da contexto del crecimiento sin overwhelm de
listing completo.
Limitación documentada: los "recent" no son cronológicos — sled
ordena lexicográfico por hash. Para timeline real, agregar
timestamp al schema (cambio breaking del store, scope futuro).
### feat(minga-explorer): nueva app dashboard del repo Minga sobre stack yahweh
Iter 11. Cierra el último frente identificado: integración del
módulo Minga (VCS semántico P2P) al ecosistema GUI. Antes Minga
sólo tenía CLI (`minga init/status/ingest/listen/sync/watch`).
Ahora hay un **dashboard GPUI** que muestra los counts del repo
en vivo, sobre el mismo stack themed que las otras dos apps
explorer.
Crate nuevo `crates/apps/minga-explorer/`:
- **Deps**: `minga-store` (para `PersistentRepo::open`) +
`yahweh-theme` + `yahweh-widget-{banner,card,theme-switcher}`.
Sin `minga-cli` (no necesita prompts de passphrase) ni
`minga-core` (counts no requieren parsear AST).
- **Lectura sin passphrase**: el `PersistentRepo` se abre directo
desde `<repo>/repo` sled. Los counts (`nodes.len()`,
`attestations.len()`, `mst.len()`) son lectura pública. Para el
DID se sigue necesitando `minga status` (CLI con passphrase).
- **Refresh por polling cada 2s**: mismo pattern que
`nakui-explorer`/`nouser-explorer`.
- **3 stat cards** una por dimensión:
- Nodos AST (cyan) — fragments parseados del código.
- Atestaciones (verde) — firmas Ed25519 sobre los nodos.
- Claves MST (purple) — entradas del Merkle Search Tree.
- **Helper `stat_card(cx, label, value, description, accent, ...)`**:
fabrica una card con border-l colored + label tenue + número
grande (`px(28)`) + descripción. Reutilizable.
- **Header**: título dinámico (`Repo: <path> · reload <ms> ms`)
+ theme switcher derecha.
- **Error banner**: themed Banner::Error si el repo no abre.
- 2 tests: `load_snapshot_errors_on_missing_dir` (msg claro
cuando el dir no existe) + sanity del `RepoSnapshot::default`.
Workspace: nueva entry en `members[]`.
Smoke run del binario verificado: bootstrap completo OK, panic
esperado en open_window por falta de display.
Beneficio operativo:
- Un usuario corre `minga init` + `minga ingest archivo.rs` desde
CLI, después abre `minga-explorer` y ve los counts crecer en
vivo cuando ingiere más archivos.
- Comparte theme switcher con `nakui-explorer` y
`nouser-explorer` — cualquier preset elegido se aplica
visualmente igual cross-app.
- `minga` deja de ser sólo CLI; gana presencia GUI sin tocar
el resto del módulo.
Apps GUI integradas al stack themed: **4** (nakui-ui, nakui-explorer,
nouser-explorer, minga-explorer).
### feat(minga-core): α-hashing per-language para Python, TypeScript, JavaScript, Go
Cierra el último pendiente fundamentado del CHANGELOG. Cada lenguaje
soportado por `minga` tiene ahora su propio profile α-equivalente —
dos versiones del mismo programa que difieren sólo en nombres de
variables ligadas producen el mismo hash, no importa el lenguaje.
Refactorings tipo "rename variable" no inflan el storage del repo
en ningún dialecto.
Refactor de `alpha.rs` (639 LOC) a módulo `alpha/`:
- **`alpha/common.rs`**: primitives compartidos (TAG_*, write_kind_and_field,
emit_leaf_marker, emit_binder_body, emit_identifier_ref, push_identifier_name).
Garantiza que el formato wire del hash sea bit-equivalente entre
todos los profiles.
- **`alpha/rust.rs`**: la lógica de Rust (movida desde alpha.rs sin
cambios funcionales).
- **`alpha/python.rs`**: nuevo.
- **`alpha/ecmascript.rs`**: nuevo (cubre TypeScript + JavaScript;
comparten la mayoría de los kinds).
- **`alpha/go.rs`**: nuevo.
- **`alpha/mod.rs`**: re-exporta `hash_node_alpha` (Rust legacy) +
expone `hash_alpha_with(dialect, node)` que despacha al profile
correspondiente.
Cobertura per-language:
**Python** (`def`, `lambda`, `for`, comprehensions, `with`):
- `function_definition` y `lambda`: parámetros (incluyendo
typed_parameter, default_parameter, *args, **kwargs) introducen
binders al body. El nombre de la función NO es α-anónimo.
- `for_statement`: el `left` (identifier o tuple) introduce
binder(es) al body.
- `list_comprehension`, `set_comprehension`, `dictionary_comprehension`,
`generator_expression`: cada `for_in_clause` añade binders que
viven en el body + clauses siguientes (semántica de scope
incremental de Python).
- `with_statement`: `as` introduce binder al body (recursando en
`as_pattern_target` para llegar al identifier).
**ECMAScript** (TS + JS):
- `function_declaration`, `function_expression`, `method_definition`,
`generator_function_*`: parameters → body. Soporta TS
`required_parameter` y `optional_parameter` (`x: number`,
`x?: number`).
- `arrow_function`: tanto `(x, y) => body` como shorthand `x => body`.
- `statement_block`: `lexical_declaration` (let/const) y
`variable_declaration` (var) introducen binders al resto del block.
- `for_in_statement` (cubre `for-of` y `for-in`): `left` → body.
- `for_statement` (C-style): initializer (lexical decl) introduce
binders al condition + increment + body.
- `catch_clause`: parameter → body.
**Go**:
- `function_declaration`, `method_declaration`, `func_literal` (closure):
`parameter_list` → body. `parameter_declaration` con varios names
agrupa varios binders bajo un mismo tipo (`a, b int`).
- `block`: `short_var_declaration` (`x := ...`) introduce binders
al resto.
- `for_statement` con `range_clause` (`for k, v := range m`): los
identifiers del `left` son binders al body.
- `for_statement` con `for_clause` (C-style): initializer → body.
- `if_statement` con `initializer` (`if x := init(); x > 0`):
binders viven en condition + consequence + alternative.
API:
- `hash_alpha_with(Dialect, &SemanticNode) -> ContentHash`
despacho per-dialect.
- `hash_node_alpha(&SemanticNode) -> ContentHash` — alias histórico
asume Rust (back-compat).
Tests: 26 nuevos en `tests/alpha_polyglot.rs`:
- Python (9): def rename, lambda rename, for-loop rename, list comp,
nested comp, with rename, function name matters, iterable name
matters, sanity negativo (operación distinta → hash distinto).
- JS/TS (9): function rename, function name matters, arrow rename,
arrow shorthand rename, let/const rename, for-of rename, classic
for rename, catch rename, TS typed param rename, TS type matters.
- Go (6): function rename, function name matters, short var decl
rename, range_clause rename, if-init rename, func_literal closure
rename.
- Cross-language (1): mismos shapes en lenguajes distintos
producen hashes distintos (sanity para evitar colisiones).
141 tests verdes en minga-core (115 antes; +26 polyglot). Refactor
sin regresión: 36 α-Rust tests siguen pasando.
Pendientes que quedan en Minga (orden de prioridad):
- `minga-vfs` FUSE (proyecto independiente, scope grande).
- Cobertura adicional por-lenguaje: Python class, JS destructuring,
Go type_switch, etc. — cada uno pequeño, no urgente.
### feat(minga-core): cierre del α-hashing de Rust — if let, while let, let-else, or-pattern, let-chains
Cierra los 5 pendientes documentados en `alpha.rs`. El hash
α-equivalente ahora es estable bajo renombre de TODOS los binders
de Rust, no sólo los del MVP (parámetros, let, for, match arms).
Pendientes cerrados:
- **`if let X = expr { ... }`**: `if_expression` detecta
`let_condition` en su `condition`, recolecta los binders del
pattern, los propaga al `consequence`. El `alternative` (else)
NO los ve.
- **`while let X = expr { ... }`**: simétrico al if-let, propaga al
`body`. El `condition` mismo se evalúa con scope previo (los
binders todavía no existen).
- **`let-else`**: `let_declaration` con campo `alternative`. El
alternative se procesa con el scope ANTES de los binders (ya
funcionaba: `feed_let` llama `feed` para no-pattern children con
el scope actual; `feed_block` extiende el scope DESPUÉS de
`feed_let`).
- **`or_pattern`**: en `pat1 | pat2` (Rust enforcement: ambos lados
introducen los mismos binders). Para emit, recorremos cada lado
con `feed_pattern`. Para collect, sólo el primer lado — iterar
todos duplicaría binders y rompería los índices de Bruijn.
- **let-chains** (`if let X = a && let Y = b { ... }`): el
`collect_let_condition_binders` recursa en el árbol del condition,
capturando todos los `let_condition` (vivan dentro de
`binary_expression` u otros nodos). Ambos binders quedan en scope
del consequence.
Helper nuevo: `feed_let_condition` para que el `pattern` del
let_condition pase por `feed_pattern` (que distingue binders vs
constructors). Sin esto, los identifiers del pattern se hasheaban
como variables libres y `Some(x)``Some(y)` aún teniendo el
mismo significado.
Tests: 6 nuevos en `tests/alpha_invariants.rs`:
- `alpha_if_let_binder_rename_invariant`
- `alpha_if_let_else_does_not_see_binder` (sanity)
- `alpha_while_let_binder_rename_invariant`
- `alpha_let_else_binder_rename_invariant`
- `alpha_or_pattern_binder_rename_invariant`
- `alpha_let_chain_binders_propagate_to_consequence`
- `alpha_if_let_does_not_collide_with_unrelated_program` (negativo:
programas distintos NO deben dar el mismo hash)
36 tests α verdes (eran 30). 115 tests totales en minga-core.
Lo que esto significa: el hash α-equivalente de Rust en minga es
**completo** — cubre todos los constructos del lenguaje que
introducen bindings. Dos versiones del mismo programa que difieren
sólo en nombres de variables (incluyendo en `if let`, `while let`,
`or-pattern`, etc.) producen el mismo hash y por tanto la misma
identidad CAS. Refactorings del tipo "rename variable" no inflan
el storage del repo.
Pendientes futuros:
- α-hashing per-language (Python: def/lambda/comprehensions; TS/JS:
function/arrow/destructuring; Go: func/closure). Cada uno
requiere conocimiento profundo de la gramática y tests
exhaustivos. Plantilla genérica no aplica.
### feat(minga): multi-lenguaje en parser — Python, TypeScript, JavaScript, Go
Minga deja de ser Rust-only. Cualquiera de los cinco dialectos
(Rust + 4 nuevos) se ingresa al CAS por su AST normalizado, hashea
estructuralmente, sincroniza por DHT como cualquier nodo. La
auto-detección por extensión hace que `minga ingest archivo.py` o
`.ts` o `.go` "simplemente funcione".
API nueva en `minga_core::parse`:
- Funciones por dialecto (~6 LOC c/u sobre el `parse_with` común):
`python`, `typescript`, `javascript`, `go`. Más la `rust` existente.
- Enum `Dialect` con `parse(source) -> Result<SemanticNode>` y
`name() -> &'static str` para logging.
- `detect_by_extension(ext) -> Option<Dialect>`: mapea `rs`/`py`/
`pyi`/`ts`/`js`/`mjs`/`cjs`/`go` (case-insensitive). `None` para
extensiones desconocidas — el caller decide si es error o se
ignora silente.
Wire en `minga-cli`:
- `cmd_ingest` deja de hardcodear `parse::rust` — usa
`detect_dialect(file)?.parse(...)`. Acepta `.py`, `.ts`, `.js`,
`.go` además de `.rs`.
- `initial_scan` y `cmd_watch` cambian `is_rs_file``is_supported_source`
para incluir todas las extensiones soportadas en el filtro.
- `CliError::UnsupportedLanguage { path, extension }` nuevo, con
mensaje que lista las extensiones reconocidas.
Notas sobre hashing:
- El AST normalizado (`SemanticNode`) descarta whitespace y
comentarios — propiedad universal de tree-sitter (extras). Misma
lógica para los 5 dialectos.
- Hashing **estructural** (`cas::hash_node`) funciona para todos:
dos textos semánticamente equivalentes-por-estructura producen el
mismo hash. NO α-equivalente (las variables ligadas distinguen).
- Hashing **α-equivalente** (`alpha::hash_node_alpha`) sigue siendo
Rust-only: cada lenguaje tiene reglas distintas para qué es
binder vs. constructor (def/lambda en Python, arrow functions en
TS/JS, func + closures en Go). Implementación per-language queda
como work futuro — requiere conocimiento profundo de cada
gramática y no se plantilla genéricamente.
- Sanity test `structural_hash_distinguishes_languages` verifica
que `x = 1` parseado como Python ≠ parseado como JavaScript: las
gramáticas no comparten kinds y los hashes salen distintos.
Importante para evitar colisiones cuando el mismo source se
ingresa bajo dialectos distintos.
Deps nuevas (workspace + minga-core):
- `tree-sitter-python = "0.23"`
- `tree-sitter-typescript = "0.23"` (sólo el modo `LANGUAGE_TYPESCRIPT`,
no TSX — bumpear a TSX es agregar otro dialecto cuando se necesite).
- `tree-sitter-javascript = "0.23"`
- `tree-sitter-go = "0.23"`
Tests:
- 9 nuevos en `parse::tests`: parse básico para los 5 dialectos
(Python con type hints, TS con tipos, JS sin tipos, Go con
package declaration), `detect_by_extension` canonical +
case-insensitive, `dialect_name`, `structural_hash_distinguishes_languages`.
- 108 tests verdes en minga-core (39 → 48 unit + integration tests
pre-existentes intactos).
- 10 tests verdes en minga-cli (sin regresión en el path Rust;
el refactor a `detect_dialect`/`is_supported_source` no rompe
nada).
Pendientes futuros del changelog:
- α-hashing per-language (Python: def/lambda/comprehensions;
TS/JS: function/arrow/destructuring; Go: func/closure). Trabajo
profundo, scope independiente.
- α-Rust pendientes documentados en `alpha.rs`: `if let`,
`while let`, `let-else`, let-chains, `or_pattern` con bindings.
+81
View File
@@ -0,0 +1,81 @@
# Changelog — misc
Entradas que no encajan en otro proyecto (chore, ci, gitignore, etc.).
### chore(.gitignore): excluir .claude/ (state local de Claude Code)
Iter 18. Side cleanup tras debugging: `.claude/` aparecía en
`git status` cada sesión (contenía `scheduled_tasks.lock` y
`settings.local.json`, ambos local-only). Excluido para que no se
commitee accidentalmente y para que `git status` quede limpio.
Investigación previa que motivó el cleanup: persiguiendo un supuesto
deadlock en `drift_check_surfaces_expected_per_record_diffs` con
eprintlns/macro de log a archivo en `drift.rs` y `run.rs`. Conclusión:
no hay deadlock — pasa cleanly aislado, en suite nakui-core, y en
`cargo test --workspace`. El "hang" original venía de procesos cargo
y test-binaries huérfanos de sesiones anteriores compitiendo por el
build lock. Source restaurado, ningún cambio funcional. Memoria
`project_drift_hang.md` reescrita con el playbook correcto.
### feat(explorer+daemon): discovery dinámico vía broker + query socket
La UI deja de hardcodear el socket admin: ahora descubre al daemon
nouser vía `MatchEvent::Available` del broker brahman y le consulta
sus Mónadas directo, sin pasar por brahman-admin. Cierra el "explorer
encuentra al daemon de forma totalmente dinámica" del meta-plan.
Pipeline end-to-end:
- Daemon publica engine Card con `service_socket = $XDG_RUNTIME_DIR/nouser-engine.sock`
y `flow.output = monad-list:json`.
- Daemon binda un Unix socket en ese path y monta un listener
blocking que sirve `nouser_card::query::QueryRequest::ListMonads`,
responde `ListMonadsResponse { engine, monads: Vec<MonadView> }`.
- Explorer construye un consumer Card con `flow.input = monad-list:json`
vía `brahman_sidecar::build_consumer_card`, llama
`await_provider_blocking(card, 3s)` y recibe el socket descubierto.
- Cachea ese socket; cada poll (2s) llama
`nouser_core::engine_socket::client::list_monads(socket, 2s)`.
Fallo de query → invalida cache → próximo tick re-descubre.
Wire types nuevos en `nouser_card::query`:
- `QueryRequest::ListMonads` (single variant por ahora).
- `ListMonadsResponse { engine: EngineInfo, monads: Vec<MonadView> }`.
- `MonadView`: proyección slim de `MonadManifest` SIN `centroid` ni
`members` — la UI no los necesita y eran KB por Mónada que no
tenían por qué viajar cada poll.
- `transport::default_socket_path()` con env override
`NOUSER_ENGINE_SOCKET`.
- Const `FLOW_MONAD_LIST = "monad-list"`, `FLOW_TYPE_NAME = "json"`.
Listener en `nouser_core::engine_socket`:
- `spawn_listener(config, db)` arma std::os::unix::net::UnixListener
en thread blocking dedicado. Frecuencia esperada (UI cada 2s) no
amerita tokio.
- `client::list_monads(socket, timeout)` — cliente blocking con
`QueryError` tipado (Connect / Io / Serde / Daemon / Timeout / Empty).
- 3 tests integración: roundtrip vacío, Mónadas reales, request
inválido devuelve ErrorResponse.
Refactor explorer:
- Drop dep `brahman-admin`, add deps `brahman-sidecar`, `nouser-card`,
`nouser-core`.
- State: `socket: Option<PathBuf>` cache + `snapshot: Option<ListMonadsResponse>`
+ `socket_source: "discovery"|"cache"` (sólo informativo).
- Tick: `tick(prior_socket)` separado del UI, devuelve un enum
`TickOutcome::{Ok, DiscoveryFailed, QueryFailed}`. Cualquier
fallo invalida la cache → re-discovery automática.
- Header reformulado: `Engine 'nouser_engine' · N mónada(s) ·
socket: /... (cache|discovery) · watching: /tmp/x`.
- Render pintado de un engine card + Mónadas, sin ya iterar
`BrokeredCard` del admin.
Trade-offs aceptados:
- Polling 2s (no streaming). El broker no empuja cambios de Data
cards hoy; agregar streaming requiere extender el protocolo
handshake. Para snapshot UI, polling 2s es suficiente.
- Re-descubrimiento full en cada error de query (en lugar de retry
con backoff). Discovery es barato (~ms vs broker), no vale la
pena la complejidad.
Tests: 10 (nouser-card, +3 query) + 27 (nouser-core, +3 engine_socket)
+ 4 (sidecar) verdes. Explorer compila clean.
File diff suppressed because it is too large Load Diff
File diff suppressed because it is too large Load Diff
File diff suppressed because it is too large Load Diff