Yaşayan bilgi tabanı
Bir projeyi getir, SecondOS onun hakkında okunabilir dokümanlardan oluşan koca bir aile yazsın, sonra kimse bakımını yapmadan her push'ta güncel tutsun. Codebase'inin ikinci beyni.
Ne elde edersin
On bir doküman, her biri projenin haritasından ve ekibinin hafızalarından farklı bir dilimden yazılır:
| Doküman | Şundan yazılır | Neyi kapsar |
|---|---|---|
| Overview | map + memory | İndeks — projenin ne olduğu, temel kararlar, şeylerin nerede durduğu ve geri kalanına işaretler. |
| Architecture | map | Modül haritası ve bir isteğin/verinin uçtan uca nasıl aktığı. |
| Modules | map + graph + schema | Modül-başına bir referans — amaç, temel export'lar, bağımlılıkları, tanımladığı route'lar ve dokunduğu DB tabloları. Büyük modüller alt-modüllere bölünür. |
| Dependencies | graph | Modül bağımlılık haritası: hangi modüller temel (çok kişi tarafından kullanılan) hangileri yaprak (çok şeye bağlı). |
| API | routes | Her HTTP route'u, onu tanımlayan modüle göre gruplanmış. |
| Data model | schema | Veritabanı şeması — tablo başına bir bölüm, kolonları, tipleri ve enum'larıyla. |
| Knowledge | memory | Ekibin kayıtlı kararları, konvansiyonları ve tuzakları, okunabilir düzyazıya dönüştürülmüş. |
| Learnings | memory | Ekibin codebase hakkında öğrendiklerinin akan bir kaydı. |
| Onboarding | map + memory | Yeni bir mühendisin nasıl başladığı — arazinin durumu, izlenecek konvansiyonlar, kaçınılacak tuzaklar. |
| Changes | git | Son zamanlarda neyin değiştiğinin, temalara gruplanmış okunabilir bir özeti. |
| Glossary | map | Temel export edilmiş sembol'ler, her biri sade bir açıklamayla. |
Nasıl çalışır
- Bir projeyi getir — senkronla (
bunx @secondos/cli push .) veya GitHub'ı bağla. İlk senkronda uygun dokümanlar kendilerini yazar. - Her push onları tazeler — her doküman bölümlere ayrılır ve her bölüm onu besleyen harita/hafıza dilimiyle içerik-adreslenir. Bir tazeleme, modeli yalnızca girdisi değişen bölümler için yeniden çalıştırır; dokunulmamış her bölüm bit-bit aynı kalır, sıfır maliyetle.
- Hafıza-türevi dokümanlar zamanla dolar — knowledge ve learnings, proje hafızaları kabul ettikten sonra belirir ve ekibin daha çok kayıt tuttukça büyür.
Neden farklı
- Asla çürümez. Dokümanlar güncel koddan yeniden üretilir, yani el-yazımı bir
CONTEXT.md'nin yaptığı gibi tarihi geçemezler. - Yalnızca bizde olanı kullanır. Çağrı/import grafiği, route'lar ve DB şeması sayesinde bağımlılık haritası, API referansı ve veri modeli, başka hiçbir aracın otomatik yazamayacağı dokümanlardır.
- Kaynağın evde kalır. Her şey yapısal haritadan yazılır — path'ler, imzalar, route'lar, modül düzeni — asla kaynak gövdelerinden değil (K‑S23).
- Hiçbir bakım yapmazsın. Bir kez bağla; bilgi tabanı kendi kendine güncel kalır.
- Her AI aracı okuyabilir. Dokümanlar sadece bir web sekmesi değil:
read_living_docMCP aracı, aynı harita-türevi architecture, overview, module ve API dokümanlarını doğrudan ajanına sunar, böylece o, yeniden türetmek yerine birinin zaten yazdığını okur. Salt-okunur ve ücretsiz.
Yaşayan bilgi tabanı bir Pro özelliğidir — tekrarlayan üretim sunucu tarafında çalışır, yani kendi model credential'larına ihtiyacın olmaz. Projenin Knowledge sekmesinde oku veya herhangi bir dokümanı isteğe bağlı üret.
Sonraki
Hafızanın ve grafiğin nasıl uyuştuğu için ürün genel bakışı'na, AI araçlarının tüm bunları nasıl okuduğu için MCP sunucusu'na veya fiyatlandırma'ya bak.