Mizan
Docs
GitHub ↗ the family ↗

Mizan Sistemi — Kullanım Kılavuzu (v1.0)

Kanıt-katmanlı araştırma ve mühendislik disiplini: kurulum, akışlar, kurallar

Bu kılavuz kalıcı referanstır. Sistemin üç katmanı, ChatGPT önerisinin denetiminden ayakta kalan mimariye dayanır — gerisi atılmıştır:

Katman Bileşen Sorumluluğu Nerede yaşar
Davranış userPreferences + Mizan Proje Talimatı AI nasıl davranır Claude ayarları + Project instructions
Denetim Mizan skill (v3.0) Bir iddia nasıl değerlendirilir Skill olarak yüklü
Veri mizan-registry.yaml Araştırma bilgisi nasıl saklanır Proje bilgisi / repo

Üç katman bağımsız çalışır: skill’siz şema da okunur, şemasız skill de denetler. Birlikte tam sistemdir.

1. Kurulum (bir kez)

  1. Skill: mizan.skill dosyasını Claude’a yükleyin (Ayarlar → Capabilities → Skills). Güncellemelerde eski sürümün üzerine yenisini yükleyin — otomatik güncellenmez. Şu anki sürüm: v3.0 (7 mod + şema).
  2. Proje talimatı: Mizan_Proje_Talimati.md içindeki bloğu, Mizan ile çalışacağınız her Claude Project’in “Project instructions” alanına yapıştırın.
  3. Şema: mizan-registry.yaml şablonunu kopyalayıp proje adınızla doldurun; Project knowledge’a dosya olarak ekleyin VEYA repo’nuzda tutun (önerilen: repo’da — git diff’i şemanın tasarım gerekçesidir).
  4. Diğer AI’lar için: şema ve Türkçe dokümantasyon model-bağımsızdır. ChatGPT/Gemini’ye şema dosyası + Mizan_TR_Dokumantasyon.md verilirse aynı disiplinle (daha zayıf tetiklenme garantisiyle) çalışırlar.

2. Günlük akışlar

2.1 Yeni hipotez (önkayıt)

Test edilebilir bir iddia doğduğunda: “Bunu registry’ye önkaydet” deyin veya Claude’un önerisini onaylayın. Claude şema formatında H-girdisi üretir — eşik ve çürütme koşulu SONUÇ GÖRÜLMEDEN kilitlenir. Girdiyi registry dosyanıza ekleyin (Claude proje bilgisindeki dosyayı doğrudan değiştiremez; güncel bloğu üretir, siz yapıştırırsınız — repo’da çalışıyorsanız Claude Code doğrudan yazabilir).

2.2 Deney ve sonuç

Deney girdisinde iki alan pazarlıksızdır: baseline (yoksa yazılı gerekçe; baseline’sız deney hiçbir hipotezi [K]’ya taşıyamaz) ve confound_controls (hipotezin confound listesindeki her madde ya kontrol edilir ya açıkça risk olarak kabul edilir). Sonuç bloğu append-only’dir; honesty_annexes boş olamaz.

2.3 Sürpriz pozitif protokolü

Sonuç beklenenden iyiyse surprising_positive: true işaretlenir ve [K]-terfisi simetrik kontrolü bekler (“bu spesifik mekanizma mı, jenerik alternatif mi?”). Manşet, kontrolden sonra atılır.

2.4 Denetim istekleri (Mod 1)

Herhangi bir iddia setini — AI özeti, rapor, öz-değerlendirme — “Mizan’la denetle” diyerek verin. Çıktı: kapsam beyanı, katmanlı iddia tablosu, karşı-örnek taraması, isabet oranı, eksik kart, sonraki adımlar.

2.5 Kod denetimi (Mod 3)

“Bu repoyu/modülü Mizan’la denetle.” Claude iddia envanteri çıkarır (testler → yorumlar → adlar → dokümanlar), her sıçramayı ayrı doğrular (yorumun varlığı ≠ davranışın varlığı), kanıt-katmanlı davranış raporu + Boşluk Haritası üretir. Dokümansız projede bu rapor dokümantasyonun kendisidir. Büyük kod tabanında kapsam beyanı zorunludur — örneklenmiş denetim tam denetim gibi sunulmaz. Tek geçişe sığmayacak kadar büyük bir repoda tam kapsam istiyorsan Claude’dan fazlamasını iste: tek bir append-only registry ve bir Coverage Ledger’ı paylaşan sıralı dilimler (prosedür: yazilim-modlari.md §A5.1) — tüm repoyu tek oturumda tutmaya gerek kalmaz.

2.6 Bug avı (Mod 4)

Debug’a başlarken: “Bug hipotezi olarak kaydet.” Semptom (yorumsuz), mekanizma hipotezi (yanlış çıkabilecek kadar spesifik), rakip hipotez ve çürütme testi kaydedilir. “Düzeltme çalıştı” sürpriz pozitiftir: geri-al-kontrolü yapılmadan mekanizma [K] olmaz. 10-15 girdiden sonra gerçek bug-sezgisi isabet oranınız çıkar.

2.7 Özellik kapısı (Mod 5)

Yeni özellik/PRD’de: “Bunu kapıdan geçir.” PRD atomize edilir (problem/ değer/maliyet/bağımlılık/kapsam iddiaları katmanlanır — bağımlılık iddiaları sprint ortasında değil ŞİMDİ doğrulanır), başarı eşiği VE kaldırma koşulu önkaydedilir, alternatif-zorlama uygulanır (≥1 ucuz alternatif + null alternatif, aynı metrikte). Kabul kriterleri çürütme dilinde yazılır. Boşluk Haritası’ndan gelen adaylar kanıt taşıyan hazır backlog’dur.

2.8b Güvenlik probu (Mod 7)

“Güvenlik probunu koş.” Mod 3-5, birinin yazdığı bir cümleden başlar; bir güvenlik açığı ise kimsenin yazmadığı cümledir, dolayısıyla o motor oraya ulaşamaz. Mod 7 önce güven sınırlarını haritalar – karşı tarafta kim var, neyi kontrol ediyor, ve beri taraf onun hakkında ne VARSAYIYOR – ve senaryoları yapanlardan değil bir tehdit modelinden türetir; çünkü kimse farkında olmadan yaptığı varsayımı adlandıramaz. Katman kuralı terstir: sömürülmemiş olmak geçer not değildir. Başarısız bir deneme ve temiz bir tarayıcı sessizliktir ve girdiyi [KKE] ile sınırlar (R26); yalnızca adı konmuş ve varlığa giden her yolda gösterilmiş bir kontrol terfi ettirir. Hiçbir şey bulamayan bir Mod 7 pası, temiz kağıt değil [KKE] kapsam beyanı üretir.

2.8 Meta-inceleme (Mod 6)

Her ~10 girdide veya istekle: hangi hipotez türleri isabetli, hangi enstrümanlar güvenilir, yanlılık nerede birikiyor. Çıktı metodolojiyi besler — talimat ve şema da revizyona tabidir (kendi disiplinlerine uyarak: değişiklik gerekçeli, geçmiş silinmez).

3. Sert kurallar (özet — şemadaki R1–R28)

  1. Sonuçtan önce eşik + çürütme koşulu (HARKing yapısal olarak kapalı).
  2. Baseline zorunlu; baseline’sız sonuç [K] üretemez.
  3. Her confound ya kontrollü ya açıkça kabul edilmiş risk.
  4. Geçmiş append-only; [R] silinmez.
  5. Dürüstlük şerhleri boş olamaz.
  6. Sürpriz pozitif → terfiden önce simetrik kontrol.
  7. Üretici ≠ tek denetçi: tier değişikliği önerilir, sahip/ayrı denetim onaylar. (RSI-güvenliği: kendi sonucunu yazan ajan kendi hipotezini terfi ettiremez.)
  8. Her eşik hakemini isimlendirir — hükmü veren merci (runtime / instrument / third_party / author / none). Kendi kendini yargılayan iddia (author) kalıcı [KKE] taşır, asla [K] olamaz; hakem yoksa (none) eşik dekoratiftir ve girdi [S]‘de kalır. Yazılım dışında — runtime artık senin yerine karar vermezken — disiplini dürüst tutan şey budur.

Şema 1.4 ile dört kural daha geliyor; her biri, prozanın zaten yasakladığı bir şeye şemanın izin verdiği yeri kapatıyor:

  1. [K] girdisi, eşiğini karşılamış bir sonuçla ya da gösterilmiş bir dış kaynakla desteklenir. Tier’ı yazmak, onu hak etmekle aynı şey değildir. Prior art saymaz: akrabalar özgünlük bağlamıdır, bu iddianın kanıtı değil.
  2. Eşikler bir nicelik adlandırır. “İyileştirir” kılavuzun kendi karşı- örneğidir; nadir kategorik hüküm için açık bir kaçış kapısı var (non_numeric_justification).
  3. Her girdi bir tier taşır. Eski kontrol yalnızca var olan bir tier’ın yazımını doğruluyordu.
  4. Zorunlu girdi alanları mevcuttur: formal, enstrümanı adlandırılmış metric, cost, status, ve mevcut prior_art — “bilinen akraba yok” bir cevaptır, alanın yokluğu sessizliktir.

Şema 1.3’ten itibaren üç kural daha, özelleşmiş bloklar için. Bir bug girdisi ve bir feature gate’i birer hipotezDİR — aynı alanlar, aynı 1–8 kuralları — üstüne:

  1. Feature kaldırma koşulunu adlandırır: onu kaldırmayı haklı çıkaracak yayın-sonrası ölçüm. Bu olmadan yalnızca maliyet biriktirebilir, çünkü onu bitirecek hiçbir şey tanımlı değildir.
  2. Feature alternatiflerini listeler: en az bir ucuz seçenek ve null alternatif (“hiçbir şey yapma”), aynı değer metriği üzerinde fiyatlanmış. Kimsenin ihtiyaç duymadığı özellik burada, inşa edilmeden önce ölür.
  3. Bug en az bir rakip hipotez adlandırır — aynı semptomu üreten başka bir mekanizma. Rakibi olmayan mekanizma hikâyedir: onu akla ilk gelen açıklamadan ayıran hiçbir şey yoktur.

1.0–1.4 beyan eden registry’ler uygulanmadan çalışmaya devam eder; girdiler hazır olduğunda sürümü yükseltin. Dağıtılan şemanın sürümü, skill/mizan/schemas/mizan-registry.yaml dosyasının başlığında yazandır.

  1. Kapsam iddiası uzlaştırmayı bekler. Fazlı denetimde coverage bloğunun claim_tier‘ı ancak her faz satırı ve MERGE satırı bittiğinde [K] olabilir. “Her dilim tam denetlendi”, “hedef tam denetlendi” demek değildir; ikincisini birincisi gibi sunmak başlı başına [Y]‘dir. Defter registry’nin yanında değil içinde durur; böylece append-only kuralı satırlarını da diğer girdiler gibi korur.

  2. Açık bir hipotez review_by tarihi taşır ve o tarih geçtiğinde bir karar kaydetmek zorundadır: gerekçe ve yeni bir tarihle uzat, beklet (status: dormant), ya da kapat. Bu, bir registry’nin en sessiz çürüme biçimine karşı olan kuraldır — kimse sahte bir [K] yazmaz, girdiler yalnızca hareket etmeyi bırakır, ve bir yıl sonra önkayıt edilip hiç test edilmemiş bir hipotez yalnızca taslak olarak kalmış olandan ayırt edilemez. Registry hâlâ dolu görünür. Şema 1.6’dan itibaren uygulanır.

  3. Önkayıt ne kilitlediğini söyler. [önkayıt] etiketi taşıyan girdi üç şeyi yazar: veri durumu (veri henüz yok / var ama görülmedi / görüldü — son ikisi önkayıt edilemez, görülmüş veriye hipotez yazmak postdiction‘dır ve bunu dürüstçe söylemek doğru hamledir), durdurma kuralı (toplama ne zaman biter) ve dışlama kuralı (hangi gözlem, hangi kuralla düşer — “hiçbiri” geçerli cevaptır, boş bırakmak değil). Ne kilitlediğini söylemeyen önkayıt hiçbir şey kilitlememiştir. Şema 1.7’den itibaren.

Şema 1.8 üç kural daha ekliyor. Diğer her kural birinin yazdığı bir cümleden başlar; bu üçünün girdisi metin değildir, bu yüzden bir alan onları istemedikçe geriye hiçbir iz bırakmazlar — koşulmalarıyla atlanmaları ayırt edilemez:

  1. Alan probu kaydedilir (probes.domain): her senaryo bir durum ve bir sonuç taşır. Tier-K bir kapsam iddiası bu bloğu şart koşar — en az bir senaryo, hiçbiri unchecked değil, written_before_work: true, ve supplied_by auditor/none dışında. Bu, R8’in hakem mantığının bir üst seviyesi: denetçinin kendi uydurduğu senaryo listesi, kendi kendini yargılayan eşikle aynı şeydir. Boşluk bulunduktan sonra yazılan senaryo ise HARKing’dir ve kapsam hakkında hiçbir şey kanıtlamaz.
  2. Bileşim pası kaydedilir (probes.conjunction): tier-K kapsam iddiası en az bir çift ister ve hiçbiri unchecked kalamaz; her çift bir özelliği ve dokunabildiği mevcut garantiyi adlandırır. Atomize etmek, yalnızca bileşimde var olan kusuru yok eder; yeniden birleştirme pası kaydedilmezse hiç koşulmamış sayılır. Yeşil test paketi karşı kanıt değildir.

  3. Her kaçak bir sınıf adlandırır (probes.escaped): ya class_ref — ateşlemesi gereken kontrol — ya da class_new, bu kaçak sayesinde artık var olan prob; ve in_scope cevaplanır. Puan kartı kaçakları zaten sayıyordu ve o sayıyı “denetimin içinden oynanamayacak tek ölçü” diye adlandırıyordu. Sayı, döngü değildir: kaçak bir sınıfa dönüşene kadar bir sonrakini hiçbir şey yakalamaz. Rampası RR-13‘tür.

  4. Maliyet iddiası kolunu söyler. cost_actual, sayıları üreten enstrümanı (bir script, bir fatura, bir gösterge paneli — “model tahmin etti” enstrüman değildir), ölçüm penceresini, atfı (harcamanın bu girdiye nasıl ve kim tarafından eşlendiği — yapısı gereği insan hükmü) ve baseline.kind‘ı adlandırır: none · internal-phase · parallel-arm · historical. none meşrudur, dürüsttür ve girdiyi [K]‘nın altında tavanlar. İşin ne kadara mal olduğu bir ölçümdür; farkı aracın yarattığı ise bir iddiadır ve karşılaştırma kolu olmadan onu aynı sayıyı üreten sıkıcı açıklamalardan ayıran hiçbir şey yoktur — ekibin artık tanıdığı bir kod tabanı, küçülmüş bir backlog, bir kez çözülmüş bir probleme ikinci deneme. R2’nin, ekiplerin en sık kontrolsüz yaptığı iddiaya çevrilmiş hâli. Şema 1.9.

1.0–1.8 beyan eden registry’ler yükseltmede kırılmaz: yapısal yarı yalnızca yazdığın prob satırlarına bakar, kapı yarısı yalnızca [K] iddia eden bir coverage bloğunda ateşlenir.

23–25. kurallar, bir kullanıcının aynı gün elle bulduğu dört kusuru KAÇIRAN tek bir denetimden çıktı — dördü de dilimlerin ARASINDAYDI ve yukarıdaki kuralların hiçbiri onlara ulaşamıyordu. Her biri, yöntemin kontrol etmeden güvendiği bir yeri kapatır.

  1. MERGE, kimsenin bakmadığı çiftleri uzlaştırır. done işaretli bir MERGE satırı cross_slice taşır: gerçekten incelenen dilim sınırları, her biri bir sonuçla. Boş liste ya da her çifti unchecked olan liste düşer. Dilimler kapsayıcıya göre kesilir (modül, yol, yüzey); yalnızca bir dikişte yaşayan kusur iki dilimin bulgularında da görünmez, bu yüzden bulguları uzlaştırmak onu asla bulamaz.

  2. Denetçinin kendi enstrümanları da kalibre edilir. metric.instrument_built_by değeri auditor olan bir [K] girdisi instrument_validated taşır: o enstrümanın bilinen bir pozitife ve bilinen bir negatife karşı çalıştırıldığının kaydı. Denetim sırasında yazılan bir tarayıcı daha zayıf bir enstrüman değildir; kalibre edilmemiş bir enstrümandır.

  3. Çalışma zamanı kararı, koştuğu eseri adlandırır. runtime hakemli ve threshold_met: yes olan bir sonuç artifact_freshness taşır: hakemin denetlenen kodu çalıştırdığının nereden bilindiği. Bayat bir derleme yeşili, kırmızıyı ve tamamen geçen bir paketi aynı güvenle raporlar — bu daha zayıf bir ölçüm değil, sahte bir güvencedir. Şema 1.10.

  4. İstismar edilmemiş olmak geçmek değildir (Mod 7). security_evidence: attack_failed | scanner_silence üzerine kurulu bir girdi [K]‘da duramaz: başarısız bir saldırı tek bir saldırganın denemesidir, sessiz bir tarayıcı ise kendi kural setine dair bir beyandır. Yalnızca blocked_by yükseltir — varlığa giden her yolda adı konmuş bir kontrol (control_ref), denemeyi yapan kişiden başkası tarafından değerlendirilmiş.

  5. Bir güvenlik kapsam iddiası güven sınırlarını haritalar. security_scope: true ile [K] iddia eden bir coverage bloğu probes.adversary ister: her sınır who / controls / near_side_assumes ile, senaryolar eylem olarak yazılmış, hiçbiri unchecked değil, işten önce yazılmış ve denetçiden başkası tarafından sağlanmış. Tedarikçisi değişmiş R19: kimse hiç fark etmediği bir varsayımı adlandıramaz. Şema 1.11; prosedür references/security-probe.md içinde.

  6. Denetim, deponun ÜRETTİKLERİNİ listeler. Fazları biten bir kapsam bloğu coverage.produced_artifacts taşır — üretilen her dosya ve inspected olup olmadığı (no / partial bir why_not ister) — ya da bunu tek cümleyle feragat eder. Dilimler, bir insanın yazdığını tutan kaynak ağacından kesilir; üretilen bir config hiçbir dilimde yer almaz. Onu yakalayan, üreticiyi çalıştırıp çıktısını okumaktır. Şema 1.12.

Uyarılar (W1–W8) bloke etmez, tavsiye eder. two_sided beyanı olmayan girdi; henüz sonucu olmayan ve eşiği/çürütmesi de bulunmayan girdi; her etiketli girdisi [K] olan registry; MERGE satırı olmayan kapsam defteri; coverage bloğu olup alan ya da bileşim probu bulunmayan registry — tier-K iddiasının altında R19/R20 ateşlenmez, ve bu ikisi testlerin göremediğini bulan paslar olduğu için sessizce atlanması da en kolay olanlardır; her faz bittiği hâlde alan probu hiç cevaplanmamış registry (W6 — feragat bir karardır, sessizlik değildir); tedarik zinciri ya da CI sınırı olmayan bir saldırgan haritası (W7); ve o hakemin nasıl başarısız olduğunu söyleyen failure_is_loud satırı olmadan karşılanmış bir runtime eşiği (W8 — askıda kalan bir koşu karar döndürmez, ve kararsızlık sabır gibi okunur). Her birinin meşru istisnası var — taslak girdi, tek girdili registry — bu yüzden hiçbiri kural değil. --strict onları hataya yükseltir; CI, disiplini modellemekle yükümlü dosyalarda (şema, şablon, örnekler) strict, diğerlerinde tavsiye kipinde koşar; böylece henüz ele alınmamış bir uyarı, ilgisiz bir değişikliği bloke etmez.

4. Sık hatalar

5. İlk gerçek görev (önkayıtlı)

SpectralLM deney registry’nizin (experiment_registry_and_metrics.md) mizan-registry.yaml şemasına migrasyonu — geçen oturumda kilitlenen eşikle: şema ≥20 gerçek girdiyi yapısal yeniden-yazım gerektirmeden taşır VE en az bir kez sizin dışınızda bir araç/model tarafından okunup güncellenirse → standartlaştırma tartışması açılır. Aksi halde ORP fikri [R] ve şema kişisel araç olarak kalır — ki bu da geçerli bir sonuçtur.

6. Dosya envanteri

Dosya İçerik
mizan.skill Skill paketi v3.0 (7 mod + şema gömülü)
mizan-registry.yaml Şema şablonu (bağımsız kopya)
Mizan_Proje_Talimati.md Project instructions bloğu + fark analizi
Mizan_TR_Dokumantasyon.md Mod 1–2 tam Türkçe referans
Mizan_TR_Ek_YazilimModlari.md Mod 3–5 tam Türkçe referans
Bu kılavuz Kurulum, akışlar, kurallar