Hafıza ve Review

Proje hafızasının, review artefact'lerinin ve docs güncellemelerinin runtime gerçeğiyle nasıl hizalı tutulduğu.

Bu repo için “hafıza” ne demek

Buradaki hafıza yalnızca model hafızası değil. Aynı zamanda şunları da kapsar:

.ai/current-state.md
.ai/tasks.md
.ai/decisions.md
runtime review artefact'leri
persist edilmiş trace ve context pack'ler
mevcut çalışma varsayımlarını açıklayan docs sayfaları

Bunun önemi

Bu boyuttaki bir repo; implementasyon, docs ve çalışma varsayımları birbirinden koparsa hızla bakımı zor bir yapıya dönüşür. Gelecekteki işi yavaşlatmanın en kolay yolu, geride bayat proje hafızası bırakmaktır.

Repo hafızası ne zaman güncellenmeli

Bir değişiklik şunları etkiliyorsa .ai notlarını güncelle:

runtime davranışı
ürün yönü
geliştirici workflow'u
frontend ya da docs mimarisi
QA beklentileri
safety sınırları

Review duruşu

Şüpheli bir sonucu incelerken inspect edilebilir kanıtı tercih et:

typed provider ya da market artefact'leri
runtime state ve loglar
specialist ve manager çıktıları
persist edilmiş review snapshot'ları
UI davranışı

“Cevap yanlış hissettiriyor” noktasından doğrudan “prompt değişmeli” sonucuna atlama.

Docs sorumluluğu

Bu docs sitesi proje hafızasının bir parçası. Kalıcı bir karar değiştiğinde doğru kapanış çoğu zaman şudur:

implementasyonu güncelle
ilgili docs sayfasını güncelle
.ai/current-state.md dosyasını güncelle
.ai/decisions.md dosyasını güncelle
iş kaldıysa .ai/tasks.md dosyasını güncelle

Feedback akışının düz anlatımı

GitHub Pages docs build'i repo dosya sistemine yazamaz. Bu yüzden feedback widget'ı kısa bir taslağı tarayıcı içinde saklar ve manuel gönderim için hazır doldurulmuş GitHub issue bağlantısı üretir.

İleride Node-hosted bir docs örneği server-side feedback'i yeniden açarsa local auditability açık kalmalı ve external forwarding başarısızken başarı taklidi yapmamalı.