El daemon monta notify::recommended_watcher recursivo sobre el dir
escaneado. Cada Create/Modify de archivo regular dispara:
embedding → filtro por centroid_model → ranking contra centroides →
log con 🧲 / · según supere DEFAULT_ATTRACTION_THRESHOLD.
$ nouser daemon /tmp/x &
$ vim /tmp/x/src/nuevo.rs
[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 thread 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 + diff publish) queda
para futuro.
Limitación conocida: notify emite múltiples eventos por edición
(Create + Modify, etc.). Sin debounce el watcher reporta varias
veces. Aceptable para demo; producción conviene debounce ~100ms
por path.
Esto cierra la Fase C del plan post-reporte: el sistema "se siente"
vivo. Tocar un archivo en vim y ver inmediatamente la atracción
calculada cumple el meta-mensaje "Mónada Viva".
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Sergio
487c457e5b