sinity-lynchpin

Lynchpin est une plateforme locale d'analyse et de preuves destinée à un opérateur unique disposant d'un lac de données local de longue durée. Elle lit des données qui résident normalement dans des systèmes séparés — captures d'activité, historique terminal, activité Git et GitHub, archives de sessions IA, exports de navigateur et de communication, dossiers de santé et télémétrie machine — et les transforme en jeux de données DuckDB reproductibles, graphes de preuves, produits d'analyse et packs de contexte bornés pour humains et agents. Les données brutes restent dans le système qui en est propriétaire. Lynchpin construit des modèles de lecture avec couverture, fraîcheur et provenance explicites, afin que les résultats puissent être retracés jusqu'aux captures et exports qui les étayent. Ce n'est pas un service hébergé ; l'arborescence publique contient des parseurs réutilisables, des schémas, des analyses, des outils de requête, des tests et des fixtures neutres, tandis que les identités privées, vocabulaires, classifications, exports et narratifs générés sont fournis via une configuration externe. Les questions typiques qu'elle traite incluent : quelles sessions IA et commandes terminal ont précédé un commit, ce que faisait la machine lors de l'échec d'un build ou d'un service, comment le temps et la concentration différaient selon les projets, quelles preuves soutiennent une affirmation sur le travail ou la santé, quelles sources sont manquantes ou obsolètes, et quel contexte borné un agent devrait recevoir pour un projet ou une fenêtre temporelle. Les outils propres à chaque source restent faisant autorité ; Lynchpin rend leurs enregistrements joignables sans effacer les frontières entre sources. Le pipeline va des captures, exports, dépôts et registres de services, à travers des adaptateurs de sources typés, vers des jeux de données canoniques et des manifestes, puis vers DuckDB, d'où sont dérivés les graphes de preuves et les produits d'analyse, alimentant les packs de contexte, une CLI et MCP. Un planificateur de matérialisation détermine quels jeux de données sont manquants ou obsolètes, les reconstruit dans l'ordre des dépendances et enregistre un manifeste pour chaque résultat. Les identifiants de rafraîchissement relient les graphes et les rapports à un instantané DuckDB spécifique, maintenant la sortie narrative en aval des preuves. Les sources actuelles incluent les événements d'application et de concentration ActivityWatch ; les commandes Atuin et les enregistrements asciinema ; les dépôts Git, l'activité GitHub, les instantanés de code et les détails de revue de PR ; les profils de session et événements de travail Polylogue ; l'historique de navigation, les signets, le presse-papiers et les exports de communication ; les exports de santé, de sommeil et de médias portables ; et les métriques machine, l'état des services, les benchmarks et les générations système. Les adaptateurs préservent les réserves propres à chaque source : les observations manquantes ne deviennent pas zéro, et les jeux de données bornés par un export restent distinguables d'une capture continue. La couche DuckDB offre du SQL ordinaire et des lecteurs stables pour les commits, fichiers, symboles et historique de revue ; les événements de travail IA et profils de session ; les signaux d'activité, de concentration, de santé et de communication ; l'état machine, la pression, les services et les expériences ; et les affirmations de preuve, les arêtes de graphe et la disponibilité des sources. C'est une couche de jointure et d'accélération, non une seconde archive de données brutes. La couche de graphe relie projets, commits, fichiers, travail IA, activité terminal, plages de concentration, éléments GitHub, contexte machine, signaux personnels et affirmations d'analyse, prenant en charge la corrélation projet/jour, la corrélation session-à-commit, les chaînes de clôture issue/PR/commit, le chevauchement de fichiers et de symboles, les matrices de disponibilité des sources et de confiance, les chronologies, et les packs de contexte Markdown/JSON avec options explicites de preuves faibles. Le paquet d'analyse couvre la vélocité du code, les surfaces de changement, les cartes de dépendances, les candidats au refactoring, la comparaison entre projets, les rythmes de travail, la fragmentation de la concentration, l'efficacité des sessions IA, les signaux de santé et de sommeil, la pression machine, le chevauchement de charge de travail, le comportement des services et l'attribution calibrée. Les métriques canoniques portent une fenêtre temporelle, une unité ou un dénominateur, et un chemin d'artefact. Le serveur MCP expose huit outils publics : lynchpin_status, lynchpin_catalog, lynchpin_query, lynchpin_evidence, lynchpin_project, lynchpin_personal, lynchpin_machine et lynchpin_ops. Les chemins de lecture sont en lecture seule ; les opérations qui matérialisent ou suppriment un état local nécessitent une décision d'exécution explicite et produisent des reçus. Le développement est Nix-first (direnv allow ou nix develop), les tests s'exécutent avec pytest -q, et les points d'entrée CLI matérialisent les produits, promeuvent les fenêtres temporelles, rendent les packs de contexte d'état courant et démarrent le serveur MCP stdio. Les commandes découvrent les racines de données via LynchpinConfig et des variables d'environnement ; un checkout sans le profil privé peut toujours exécuter les tests, inspecter les schémas et les catalogues d'outils, et utiliser des fixtures neutres. Le dépôt est organisé en paquets core, sources, ingest, substrate, graph, analysis, mcp et cli, avec des tests et un répertoire d'état local .lynchpin/ ignoré. Les frontières de données empêchent les adaptateurs de sources de muter les exports bruts, maintiennent la configuration de l'opérateur hors du dépôt, et attribuent la propriété de l'ingestion des sessions IA à Polylogue, la capture d'événements à Sinex, et la configuration de l'hôte à Sinnix. Sous licence MIT.