sinity-lynchpin

Lynchpin es una plataforma local de evidencia y análisis para un operador único con un lago de datos local de larga duración. Lee datos que normalmente viven en sistemas separados — capturas de actividad, historial de terminal, actividad de Git y GitHub, archivos de sesiones de IA, exportaciones de navegador y comunicación, registros de salud y telemetría de máquinas — y los convierte en conjuntos de datos DuckDB reproducibles, grafos de evidencia, productos de análisis y paquetes de contexto acotado para humanos y agentes. Los datos crudos permanecen en el sistema que los posee. Lynchpin construye modelos de lectura con cobertura, frescura y procedencia explícitas, de modo que los resultados puedan rastrearse hasta las capturas y exportaciones que los respaldan. No es un servicio alojado; el árbol público contiene analizadores, esquemas, análisis, herramientas de consulta, pruebas y accesorios neutrales reutilizables, mientras que identidades privadas, vocabularios, clasificaciones, exportaciones y narrativas generadas se suministran mediante configuración externa. Las preguntas típicas que aborda incluyen qué sesiones de IA y comandos de terminal precedieron a una confirmación, qué estaba haciendo la máquina cuando falló una compilación o un servicio, cómo difirieron el tiempo y el enfoque entre proyectos, qué evidencia respalda una afirmación sobre trabajo o salud, qué fuentes faltan o están obsoletas, y qué contexto acotado debería recibir un agente para un proyecto o ventana de tiempo. Las herramientas específicas de cada fuente siguen siendo autoritativas; Lynchpin hace que sus registros sean unibles sin borrar los límites de las fuentes. El pipeline se ejecuta desde capturas, exportaciones, repositorios y libros de contabilidad de servicios a través de adaptadores de fuente tipados hacia conjuntos de datos canónicos y manifiestos, luego a DuckDB, del cual se derivan grafos de evidencia y productos de análisis, alimentando paquetes de contexto, una CLI y MCP. Un planificador de materialización determina qué conjuntos de datos faltan o están obsoletos, los reconstruye en orden de dependencia y registra un manifiesto para cada resultado. Los IDs de actualización conectan grafos e informes a una instantánea específica de DuckDB, manteniendo la salida narrativa aguas abajo de la evidencia. Las fuentes actuales incluyen eventos de aplicación y enfoque de ActivityWatch; comandos de Atuin y grabaciones de asciinema; repositorios de Git, actividad de GitHub, instantáneas de código y detalles de revisión de PR; perfiles de sesión y eventos de trabajo de Polylogue; historial de navegador, marcadores, portapapeles y exportaciones de comunicación; exportaciones de salud, sueño y medios portátiles; y métricas de máquina, estado de servicios, puntos de referencia y generaciones de sistemas. Los adaptadores preservan advertencias específicas de la fuente: las observaciones faltantes no se convierten en cero, y los conjuntos de datos limitados por exportación permanecen distinguibles de la captura continua. La capa DuckDB ofrece SQL ordinario y lectores estables para confirmaciones, archivos, símbolos e historial de revisión; eventos de trabajo de IA y perfiles de sesión; señales de actividad, enfoque, salud y comunicación; estado de máquina, presión, servicios y experimentos; y afirmaciones de evidencia, bordes de grafo y preparación de fuentes. Es una capa de unión y aceleración, no un segundo archivo de datos crudos. La capa de grafo conecta proyectos, confirmaciones, archivos, trabajo de IA, actividad de terminal, períodos de enfoque, elementos de GitHub, contexto de máquina, señales personales y afirmaciones de análisis, apoyando correlación proyecto/día, correlación sesión-a-confirmación, cadenas de cierre de problema/PR/confirmación, superposición de archivos y símbolos, matrices de preparación de fuentes y confianza, líneas de tiempo cronológicas y paquetes de contexto Markdown/JSON con opciones explícitas de evidencia débil. El paquete de análisis cubre velocidad de código, superficies de cambio, mapas de dependencias, candidatos de refactorización, comparación entre proyectos, ritmos de trabajo, fragmentación de enfoque, eficiencia de sesiones de IA, señales de salud y sueño, presión de máquina, superposición de carga de trabajo, comportamiento de servicios y atribución calibrada. Las métricas canónicas llevan un período de tiempo, unidad o denominador, y ruta de artefacto. El servidor MCP expone ocho herramientas públicas: lynchpin_status, lynchpin_catalog, lynchpin_query, lynchpin_evidence, lynchpin_project, lynchpin_personal, lynchpin_machine y lynchpin_ops. Las rutas de lectura son de solo lectura; las operaciones que materializan o eliminan estado local requieren una decisión de ejecución explícita y producen recibos. El desarrollo es primero en Nix (direnv allow o nix develop), las pruebas se ejecutan con pytest -q, y los puntos de entrada de CLI materializan productos, promueven ventanas de tiempo, renderizan paquetes de contexto de estado actual e inician el servidor MCP stdio. Los comandos descubren raíces de datos a través de LynchpinConfig y variables de entorno; una copia de trabajo sin el perfil privado aún puede ejecutar pruebas, inspeccionar esquemas y catálogos de herramientas, y usar accesorios neutrales. El repositorio está organizado en paquetes core, sources, ingest, substrate, graph, analysis, mcp y cli, con pruebas y un directorio de estado local .lynchpin/ ignorado. Los límites de datos impiden que los adaptadores de fuente muten exportaciones crudas, mantienen la configuración del operador fuera del repositorio y asignan la propiedad de la ingesta de sesiones de IA a Polylogue, la captura de eventos a Sinex y la configuración del host a Sinnix. Licenciado bajo MIT.