Por qué un solo servidor
El conocimiento solo cuenta cuando alguien es responsable de él, lo ha aprobado, puede verlo y sabe lo vigente que está. Un único lugar aplica esas reglas a cada lector, así que ningún cliente puede saltárselas.
Arquitectura
Cómo encaja Lore.
Un solo servidor guarda las reglas: quién es responsable de una entrada, quién puede leerla y lo vigente que está. Todo lo demás, la app que usa la gente, los asistentes y las herramientas de alrededor, llega al conocimiento solo a través de él.
Las piezas
Un servidor en el centro, y todo lector pasa por él.
Las personas usan la app; los asistentes hablan MCP. Ambos llegan al mismo servidor, que aplica el mismo acceso a cada lectura, lo guarda todo en una sola base de datos y ejecuta sus propios modelos pequeños.
Quién lee
PersonasLa app: en un navegador, la app de escritorio o Lore Local
al servidor: la app · HTTPS
AsistentesClaude Code, Codex, Cursor, Windsurf, GitHub Copilot, cualquiera que hable MCP
al servidor: MCP · el resumen
loreConecta cada asistente; ejecuta el hook y la línea de estado de Claude Code
al servidor: el hook
El servidor de LoreUn solo proceso Java. El mismo jar sirve para una persona o como réplicas en Kubernetes.
Búsquedapalabras, identificadores, erratas y significado, y después un reranker
Preguntarrespuestas con entradas aprobadas, cada una citada
Revisión y vigencianada se publica sin verse; cada entrada verificada o pendiente de revisar
Preguntas y tareaslo que nadie supo responder; indexación, fuentes, resúmenes
Acceso por áreas, aplicado dentro de cada lectura: la de la app, la de Preguntar y la de cada asistente
Postgres con pgvectorEntradas, pasajes, sus vectores, enlaces, registros y ajustes: una transacción por cambio
Tres modelos localesEmbeddings, búsqueda y reranker, dentro del servidor; ningún texto sale de él por ellos
Alrededor, cuando los añades
con el servidor: reflejados, solo lectura
ConectoresSlack, Jira, Confluence, Google Drive, Notion y Linear, con el acceso de cada fuente
con el servidor: quién escribe en Preguntar, a tu elección
Motores de respuestaUn modelo en este ordenador, Claude u otro en la nube; o ninguno, y Preguntar lista las entradas
con el servidor: buscados como uno
Otras instancias de LoreLas que una persona puede ver; sin copiar nada
con el servidor: eventos de salida
Tus otras herramientasWebhooks, o Kafka y RabbitMQ con un plugin
Por qué una sola base de datos
Una entrada, sus pasajes, sus vectores y su revisión cambian juntos o no cambian. Con los vectores junto al texto no hay un segundo almacén que mantener al día, y la copia de seguridad es un solo volcado.
Por qué modelos locales
Búsqueda por significado, entre idiomas, y un reranker que juzga si un pasaje responde a la pregunta: el motivo por el que el hook puede callarse cuando nada responde.
Una búsqueda
Un mismo proceso responde a todos.
La búsqueda de la app, la búsqueda y el resumen de un asistente, el hook, las fuentes de Preguntar y la búsqueda desde otra instancia de Lore siguen los mismos pasos.
- 1La preguntaTal como la hace quien lee, con su acceso
- 2EntendidaEl glosario del equipo y la ortografía
- 3Cuatro buscadores a la vezPalabras claveIdentificadoresErratas en títulosSignificadoCada uno solo sobre lo que quien lee puede leer
- 4Una sola puntuaciónSus señales combinadas y calibradas
- 5El rerankerLee los mejores candidatos en 150 ms
- 6El umbralLos resultados flojos nunca llegan a un asistente
El turno de un asistente
Callado, salvo que tenga algo.
En Claude Code, el hook del comando lore ve cada prompt. Cualquier asistente puede pedir por MCP un resumen de su tarea. Los dos responden solo cuando una entrada supera el umbral por sí sola.
Escribes un prompten Claude Code
El hookse lo envía a Lore, esperando dos segundos como mucho
Una búsqueda evaluadael reranker siempre lee los seis mejores
una entrada supera el umbral
Una pista, citadaañadida al contexto del prompt
ninguna lo supera: lo habitual
Nadael 98% de los prompts que no tienen que ver no recibe ni una palabra
Dónde se ejecuta
El mismo servidor, de dos formas.
Lo que cambia es quién lo arranca y de dónde sale su base de datos.
Lore Local, para una persona
Una sola app
La ventana de la appy un supervisor que arranca y para todo lo demás
El servidorcon su propio entorno de Java, solo en este ordenador
Postgressu propio puerto
Los modelostres, dentro
loreel comando, incluido
MCP · el hook, sin token
Los asistentes de este ordenador
Un servidor de equipo
El ordenador de cada personala app de escritorio o un navegador; los asistentes y
loreHTTPS, un token en cada petición
Tus servidores: compose en una máquina, o Kubernetes
Servidorréplica
Servidorréplica
Un solo Postgresincluido o gestionado; migraciones antes de cada actualización
Dónde viven los datos
Todo en una base de datos, nada guardado al margen.
El servidor no guarda ningún estado propio que una segunda réplica pudiera echar en falta. Una entrada se divide en pasajes por sus encabezados, cada pasaje recibe sus vectores, y un evento de salida se escribe en la misma transacción que el cambio del que informa, así que ninguno se pierde ni se inventa.
En Lore Local
La carpeta propia de la app, privada para ti: la base de datos, sus copias de seguridad (se guardan tres) y la caché de modelos. La contraseña de la base de datos está en el llavero del sistema.
En un servidor de equipo
La base de datos que le des. La imagen solo escribe sus repositorios clonados, sus copias de seguridad y archivos temporales; los registros van a la salida estándar.
En cada ordenador
El comando lore y una copia de seguridad de cada archivo que haya cambiado. Su token está en el llavero del sistema, nunca en un archivo.