Threadlens - Yerel yapay zeka oturumlarını arayan, analiz eden, yedekleyen ve düzenleyen açık kaynak araç

 (github.com/hanityx)
11 puan yazan hanityx 26 일 전 | 5 yorum | WhatsApp'ta paylaş

Merhaba. Birden fazla yapay zeka aracını birlikte kullanırken yaşadığım rahatsızlıkları çözmeye çalışarak ThreadLens adında bir açık kaynak araç geliştiriyorum.

İlk çıkış noktası Codex thread'lerini düzenleme ihtiyacıydı. Arayüzde yalnızca archive yapılabiliyor, gerçekten silmek içinse yerel dosyaları doğrudan bulmak gerekiyordu. Sonradan openai/codex içinde de "archive yerine delete gerekli" şeklinde benzer bir talebin açıldığını görünce, bunun yalnızca benim yaşadığım bir sorun olmadığını düşündüm.

Ardından Codex, Claude gibi çeşitli yapay zeka araçlarını dönüşümlü kullanınca başka bir sorun daha ortaya çıktı. "O zaman yapay zekayla yaptığım konuşma neredeydi?" diye her aracın gizli klasörlerini kurcalamak ya da rg ile transcript aramak sık yaşanan bir iş haline geldi; ayrıca yerel oturum logları da sürekli birikince depolamayı düzenlemek ve harici yedek almakla her seferinde elle uğraşmak zahmetli oluyordu.

Bu akışı tek bir yerde toplamak istiyorum.

  • Codex, Claude, Gemini, Copilot yerel oturumlarını tek yerden arama
  • Oturum bazında transcript, çalışma yolu, dosya boyutu, değiştirilme zamanı bilgilerini tek ekranda görme
  • Toplu yedekleme ve etki analizi üzerinden düzenleme yapma (etki analizi şu an ağırlıklı olarak Codex odaklı)
  • Sağlayıcı bazında oturum yapısının nereden ve nasıl okunduğunu routing/parser ile inceleme

Local-First yaklaşımıyla hesap veya bulut yükleme yok. Zaten bilgisayarımda bulunan oturum dosyalarını okuyup bunları yerel API, web UI, masaüstü uygulaması ve TUI içinde gösteren bir yapı.

Geliştirirken yalnızca bir "silme düğmesi" olmasının pek yeterli olmadığını hissettim. Özellikle Codex thread'lerinde, silmeden önce "Bunu silmek gerçekten sorun yaratır mı?" sorusunun yanıtını görmek istedim. Bu yüzden etki analizinde OpenAI/Claude tarafındaki dokümanlardan ve gerçek issue'larda referans alınabilecek sinyallerden yararlanıyorum; puan ağırlıklarını da ürün içinde temkinli tuttum.

Uzun context, araç ağırlıklı geçmiş, cwd varlığı/yokluğu, eski oturumlar gibi noktaların yanı sıra, başka oturumların bu thread'e ebeveyn/çocuk/fork ilişkisiyle doğrudan referans verip vermediğine ya da log içinde bundan bahsedip bahsetmediğine de bakıyor. Böylece silmeden önce bunun yetim aday olup olmadığını, başka oturumlarla bağlantılı olup olmadığını, silmenin güvenli görünüp görünmediğini önceden kontrol etmek mümkün oluyor.

Şu anda macOS DMG, Windows exe, Linux AppImage sürümleri yayımlanmış durumda ve kaynak koddan da çalıştırılabiliyor.
Masaüstü build'leri henüz unsigned olduğu için işletim sistemi uyarısı çıkabilir. Sağlayıcı bazlı tarama mantığı ve genel UX üzerinde geliştirmeler sürüyor.

Geri bildirimler ve katkı desteği memnuniyetle karşılanır!! Başka bir yerel yapay zeka oturum formatı kullanıyorsanız onu da paylaşın. Öncelikleri belirlemeye yardımcı olacaktır :)

GitHub: https://github.com/hanityx/threadlens

İlgili okumalar

5 yorum

 
minhoryang 26 일 전

Harika! Tam da şu anda gerçekten ihtiyaç duyduğum şeydi!!
 
hanityx 25 일 전

Yorumlara kadar... Asıl ben teşekkür ederim! Arayüzde Korece de destekleniyor; i18 tabanlı çok dilli bir yapı var. Bundan sonra daha da sıkı çalışıp geliştireceğim!
 
minhoryang 25 일 전

@hanityx Acaba başka provider'lar ekleyebilmek için bir rehber hazırlayabilir misiniz? (opencode ya da başka şeyler de eklemeyi denemek istiyorum.) docs/PROVIDER_SUPPORT.md içindeki bilgiler doğrudan sizin tarafınızdan mı derlendi? apps/api-ts/src/domains/providers/matrix.ts içine de elle ekleme yapmak gerekiyor mu? Arayüz ayrılırsa biraz daha kullanışlı olabilir gibi geliyor.
 
hanityx 24 일 전

Yapı, yalnızca matrix.ts eklenince yeni bir provider’ın bağlandığı şekilde değil; provider listesi, yol güvenliği, oturum bulma, transcript/search işleme, actions, health, testler ve dokümantasyon üretiminin de birlikte uyumlu hale getirilmesi gerekiyor.

docs/PROVIDER_SUPPORT.md, doğrudan elle düzenlenen bir belge değil; shared contracts içindeki provider registry ve dokümantasyon üretim betiği temel alınarak otomatik oluşturuluyor. Amaç, provider bazındaki destek kapsamının gerçek mantıkla çelişmemesini sağlamak.

Zaten API tarafındaki search/transcript mantığı epey büyüdüğü için ayırma/düzenleme işine bakıyordum; bu vesileyle provider eklemeyi kolaylaştıracak dahili adapter ve rehberi de birlikte düzenleyip, OpenCode için de önce güvenli read-only desteğini değerlendireceğim. Yerel oturum yolu, örnekler ve ilgili bilgileri issue olarak bırakırsanız, buradan devam edip bakmayı sürdüreceğim!
 
minhoryang 24 일 전

Siz sadece ayırın, ben de CONTRIBUTING.md ve rehbere göre opencode'u yüklemeyi deneyeceğim.