sinity-lynchpin

Lynchpin é uma plataforma local-first de evidências e análise para um único operador com um data lake local de longa duração. Ela lê dados que normalmente residem em sistemas separados — capturas de atividade, histórico de terminal, atividade de Git e GitHub, arquivos de sessões de IA, exportações de navegador e comunicação, registros de saúde e telemetria de máquina — e os transforma em conjuntos de dados DuckDB reproduzíveis, grafos de evidências, produtos de análise e pacotes de contexto limitados para humanos e agentes. Os dados brutos permanecem no sistema que os possui. Lynchpin constrói read models com cobertura, atualidade e proveniência explícitas, para que os resultados possam ser rastreados até as capturas e exportações que os sustentam. Não é um serviço hospedado; a árvore pública contém parsers reutilizáveis, esquemas, análises, ferramentas de consulta, testes e fixtures neutras, enquanto identidades privadas, vocabulários, classificações, exportações e narrativas geradas são fornecidos por configuração externa. Perguntas típicas que ela aborda incluem quais sessões de IA e comandos de terminal precederam um commit, o que a máquina estava fazendo quando um build ou serviço falhou, como o tempo e o foco diferiram entre projetos, quais evidências sustentam uma afirmação sobre trabalho ou saúde, quais fontes estão ausentes ou desatualizadas, e qual contexto limitado um agente deve receber para um projeto ou janela de tempo. Ferramentas específicas de cada fonte permanecem autoritativas; Lynchpin torna seus registros combináveis sem apagar as fronteiras das fontes. O pipeline vai de capturas, exportações, repositórios e ledgers de serviços, passando por adaptadores de fonte tipados, até conjuntos de dados canônicos e manifestos, e então para DuckDB, a partir do qual grafos de evidências e produtos de análise são derivados, alimentando pacotes de contexto, uma CLI e MCP. Um planejador de materialização determina quais conjuntos de dados estão ausentes ou desatualizados, os reconstrói em ordem de dependência e registra um manifesto para cada resultado. IDs de atualização conectam grafos e relatórios a um snapshot específico do DuckDB, mantendo a saída narrativa a jusante da evidência. As fontes atuais incluem eventos de aplicação e foco do ActivityWatch; comandos do Atuin e gravações do asciinema; repositórios Git, atividade do GitHub, snapshots de código e detalhes de revisão de PR; perfis de sessão e eventos de trabalho do Polylogue; histórico de navegador, favoritos, área de transferência e exportações de comunicação; exportações de saúde de wearables, sono e mídia; e métricas de máquina, estado de serviços, benchmarks e gerações de sistema. Os adaptadores preservam ressalvas específicas de cada fonte: observações ausentes não se tornam zero, e conjuntos de dados limitados por exportação permanecem distinguíveis de captura contínua. A camada DuckDB oferece SQL comum e leitores estáveis para commits, arquivos, símbolos e histórico de revisão; eventos de trabalho de IA e perfis de sessão; sinais de atividade, foco, saúde e comunicação; estado da máquina, pressão, serviços e experimentos; e afirmações de evidência, arestas de grafo e prontidão de fontes. É uma camada de junção e aceleração, não um segundo arquivo de dados brutos. A camada de grafo conecta projetos, commits, arquivos, trabalho de IA, atividade de terminal, intervalos de foco, itens do GitHub, contexto de máquina, sinais pessoais e afirmações de análise, apoiando correlação projeto/dia, correlação sessão-para-commit, cadeias de fechamento issue/PR/commit, sobreposição de arquivos e símbolos, matrizes de prontidão de fontes e confiança, linhas do tempo cronológicas e pacotes de contexto em Markdown/JSON com opções explícitas de evidência fraca. O pacote de análise cobre velocidade de código, superfícies de mudança, mapas de dependência, candidatos a refatoração, comparação entre projetos, ritmos de trabalho, fragmentação de foco, eficiência de sessões de IA, sinais de saúde e sono, pressão de máquina, sobreposição de carga de trabalho, comportamento de serviços e atribuição calibrada. Métricas canônicas carregam um período, unidade ou denominador e caminho de artefato. O servidor MCP expõe oito ferramentas públicas: lynchpin_status, lynchpin_catalog, lynchpin_query, lynchpin_evidence, lynchpin_project, lynchpin_personal, lynchpin_machine e lynchpin_ops. Os caminhos de leitura são somente leitura; operações que materializam ou removem estado local exigem uma decisão explícita de execução e produzem recibos. O desenvolvimento é Nix-first (direnv allow ou nix develop), os testes rodam com pytest -q, e os pontos de entrada da CLI materializam produtos, promovem janelas de tempo, renderizam pacotes de contexto do estado atual e iniciam o servidor MCP stdio. Os comandos descobrem raízes de dados por meio de LynchpinConfig e variáveis de ambiente; um checkout sem o perfil privado ainda pode rodar testes, inspecionar esquemas e catálogos de ferramentas e usar fixtures neutras. O repositório está organizado nos pacotes core, sources, ingest, substrate, graph, analysis, mcp e cli, com testes e um diretório de estado local .lynchpin/ ignorado. As fronteiras de dados impedem que adaptadores de fonte modifiquem exportações brutas, mantêm a configuração do operador fora do repositório e atribuem a propriedade da ingestão de sessões de IA ao Polylogue, a captura de eventos ao Sinex e a configuração de host ao Sinnix. Licenciado sob MIT.