Sergio
0ca88fdcd5
El muro no era un daemon ni un LLM — y el propio comentario de la extensión lo decía mal, copiando lo que hace willay-rag. Medido: para ordenar por parecido no hace falta ningún LLM (eso es un coseno) y el «daemon de embeddings» resultó ser el mismo llama-server que ya levanta el chat, con otro modelo. La corrección quedó escrita donde estaba la afirmación. Del lado de la suite (tawasuyu 22527f7d1 y b4ecffea8): el protocolo de llama-server salió a `shared/foreign-llama` (regla 4 — vivía dentro de puriy-costura y ya tenía dos consumidores), el `Provider` es `rimay-verbo-llama` (regla 10 — la familia verbo YA es la abstracción de embeddings, y éste es su primer backend sin nube ni descargas), y el índice es `rimay-verbo-index::VectorIndex`. Acá: la receta del modelo (multilingual-e5-small, MIT), que se pinea en fp32 y la receta CUANTIZA a Q8_0 con nuestro llama-quantize — así la procedencia es de quien declara la licencia, la imagen se lleva 126 MB en vez de 476, y la transformación es nuestra y verificable. Más el guardián y la extensión, que ahora expone `archive.ask` al lado del `archive.search` literal: son dos preguntas distintas y conviven. ⚠ El guardián está escrito pero NO corrió todavía: `ia-modelo-embeddings` quedó en la cola del flock detrás del build de otro agente. Lo medido hasta acá es el modelo a mano (384 dimensiones, el pasaje correcto gana con y sin los prefijos de e5) y 45 tests en tawasuyu. La línea del SDD que lo dice se borra cuando dé verde.
Documentación de diseño de takana
Estos documentos son la fuente de verdad del diseño. El código los implementa; cuando haya discrepancia, o se corrige el código o se actualiza el SDD con un commit que explique por qué.
Software Design Documents (SDD)
| # | Documento | Qué cubre |
|---|---|---|
| 00 | Visión y filosofía | Por qué existe, qué problema resuelve, la actitud de ingeniería |
| 01 | Arquitectura general | El modelo de dos mundos, componentes, flujo de datos |
| 02 | El laboratorio de build | Sandbox, zig cc, recetas, CAS, grafo de dependencias |
| 03 | Hidratación y store | Store content-addressed, hardlinks a FHS, patchelf, rollback |
| 04 | Overlay de experimentación | overlayfs en caliente, try/commit/discard |
| 05 | Diario de mutaciones | fanotify, log append-only, config-sin-ser-declarativa |
| 06 | Formato .swm |
Manifiesto de mutación compartible, esquema, firma |
| 07 | Bus de init y de agente | /run/init.control, /run/agent.sock, protocolo |
| 08 | Integración de la IA | El bucle agéntico, seguridad, intención → .swm |
| 09 | Modelo de confianza | Reproducibilidad, verificar-no-confiar, log de transparencia |
| 10 | Roadmap | Fases, MVP, primer entregable |
| 11 | Bootstrap from-scratch | Track posterior: Stage 0/1/2, auto-alojamiento, semilla pinned |
| 12 | arje como init real del Stage 1 |
Contrato de runtime: seed card, hammerd supervisado, CRASHED real |
| 16 | harkaq: la jaula de takana | Landlock+seccomp sobre el bwrap actual; política = clausura; evidencia negativa de hermeticidad |
| 26 | atuq: el envoltorio Gecko |
Navegador propio como artefacto DERIVADO de firefox (no fork de fuente); la toolchain clang como puerta de PGO/LTO; qué se promete y qué no |
Runbooks (operativos)
| Runbook | Para qué |
|---|---|
| Validar Stage 1 booteando en QEMU | stage0→stage1→initramfs→QEMU; criterios de éxito y troubleshooting |
Architecture Decision Records (ADR)
Decisiones tomadas, con su contexto y consecuencias. Ver adr/.