Seviye 2 · Proje Ustalığı
Kimlik hedefi: "Reposunu ajana hazırlayan kişi." Seviye 1'de tek oturumu yönettiniz; şimdi projenin kendisini AI ile çalışmaya uygun hâle getiriyorsunuz: kurallar, sigortalar, kalite kapıları ve mimariyi okuma yetisi.
Bu seviyenin kavramları: repo · commit · branch · merge · build · test · CLAUDE.md · migration · ortam değişkeni/secret · frontend/backend · prod/preview
DERS 2.1 CLAUDE.md: projenin anayasası
1 · TanımCLAUDE.md = proje klasörünün köküne koyduğunuz, AI'ın her oturumda otomatik okuduğu kurallar dosyası.
2 · İşlev ve amaçSeviye 1'de öğrendiniz: oturuma söylenen kural, compaction'da buharlaşabilir. Kalıcı kuralın yeri dosyadır. CLAUDE.md, her yeni oturuma "bu projenin görgü kurallarını" sıfır maliyetle taşır — siz tekrarlamazsınız, AI unutmaz.
3 · Nasıl yapılırDosyaya NE yazılır: (1) proje tek cümlede ne, (2) çalıştırma/test/build komutları, (3) dokunulmayacak yerler ve yasaklar ("X klasörüne dokunma", "paket ekleme, önce sor"), (4) proje kararları ("tarih formatı şu", "dil Türkçe"). NE YAZILMAZ: uzun tarihçe, genel nasihat ("temiz kod yaz"), her detay. Ölçü: kısa tutun (bir-iki ekran) — anayasa maddeleri, roman değil. İlk taslağı AI'a çıkartabilirsiniz:
Bu projeyi incele ve bir CLAUDE.md taslağı çıkar: proje özeti, komutlar, riskli
bölgeler, uyulması gereken kararlar. Kısa ve emir kipinde yaz. Ben düzelteceğim.
...ama son hâli SİZ onaylarsınız — anayasayı müteahhit yazmaz, mal sahibi onaylar.
4 · Ne ters gider + çözümüHata 1: dosya şişer, AI önemli kuralı gürültüde kaçırır. Çözüm: her yeni kural eklerken eskimiş bir satır silin. Hata 2: kural yazılır ama muğlaktır ("dikkatli ol") — uygulanamaz. Çözüm: kuralları denetlenebilir yazın ("build geçmeden commit yok" gibi evet/hayır'ı belli olan cümleler).
5 · AlternatiflerTek seferlik kısıt → istemin içine (ders 1.1). Sizin kişisel tercihiniz ama projeyle ilgisiz → memory (Seviye 3.5). Proje kuralı → CLAUDE.md. Bu üçlü yönlendirme, "nereye yazacağım" sorusunun tam cevabıdır.
6 · Denetim penceresiKontrol: yeni bir oturum açın ve sorun: "Bu projenin CLAUDE.md'sindeki kuralları listele ve her birine uyup uymadığını nasıl anlayacağımı söyle." AI kuralları eksik sayıyorsa dosya ya karışık ya şişkin. Kırmızı bayrak: AI'ın bir kuralı sistematik delmesi — kural muğlak yazılmış demektir; suç uygulayanda değil, maddede.
7 · Mini egzersiz (KENDİ-PROJEN)Üret: düşük riskli bir projenize yukarıdaki istemle CLAUDE.md taslağı çıkartın, elden geçirip 15-20 satıra indirin. Denetle: temiz oturumda 6. bölümdeki kontrolü koşturun.
8 · Kontrol soruları(1) CLAUDE.md'ye ne yazılır, ne yazılmaz? (2) "Dikkatli ol" neden kötü bir kuraldır? (3) Kural nereye yazılır: tek seferlik / kişisel / proje kuralı için üç ayrı adres nedir?
9 · Mentor istemi
VibeUni Seviye 2 Ders 2.1'in (CLAUDE.md yazımı) hocası ol. Bana kötü yazılmış 6 maddelik
örnek bir CLAUDE.md göster; hatalarını buldurup birlikte iyi versiyona çevirelim.
Sonunda 3 kontrol sorusunu sor ve değerlendir.
DERS 2.2 Git disiplini: commit = kayıt noktası
1 · TanımCommit = projenin açıklamalı fotoğrafı; branch = paralel taslak kopya; geri alma = önceki kayda dönme. Hepsini Git aracı sağlar — komutlarını AI yazar, kararlarını siz verirsiniz.
2 · İşlev ve amaçVibe coding'in ana sigortası. AI dakikada onlarca satır değiştirir; kayıt noktası yoksa "5 dakika önceki hâle dön" diyemezsiniz. Commit disiplini olan kullanıcı için AI'ın en kötü hatası bile "son kayda dön" kadar ucuzdur.
3 · Nasıl yapılırÜç kural: (1) Her sağlam adımda commit — özellik bitti + doğrulandı → kayıt. Komutu siz ezberlemeyin: "bu hâli commit'le, açıklamayı sen yaz" demek yeterli. (2) Riskli işe branch'te başla — "bu deneme için branch aç" → beğenirseniz merge, beğenmezseniz çöpe; ana kopya hiç etkilenmez. (3) Geri almanın iki modu: revert = hatalı değişikliği geri alan YENİ kayıt ekler (tarihçe korunur — güvenli, varsayılan tercih); reset = tarihçeyi geriye sarar (yıkıcı olabilir — paylaşılan projede tehlikeli). Şüphede hep revert.
4 · Ne ters gider + çözümüKlasik felaket: 4 saatlik seansta hiç commit yok, son değişiklik her şeyi bozdu, dönülecek kayıt yok. Çözüm sistemik: CLAUDE.md'ye "her doğrulanmış adımdan sonra commit öner" kuralı ekleyin — hatırlamayı kendinize bırakmayın. İkinci tuzak: anlamadan reset --hard onaylamak ve commit'lenmemiş işi kaybetmek. Çözüm: içinde hard, force geçen git komutları = ders 1.7 protokolü (açıklat, sonra karar ver).
5 · Alternatifler"Her adımda commit" yerine bazıları oturum sonunda tek büyük commit atar — geri dönüş noktalarınız seyrekleşir, riski size ait. Küçük kişisel projede kabul edilebilir; para/kullanıcı olan projede edilmez.
6 · Denetim penceresiKontrol soruları kendinize: "Şu an her şey bozulsa, en fazla kaç dakikalık işim yanar?" Cevap 30 dakikadan büyükse commit'lersiniz. AI'a: "son commit'ten bu yana neler değişti, listele" — liste sürpriz içeriyorsa önce inceleyin, sonra commit'leyin (çöp de kayda girmesin).
7 · Mini egzersiz (SANDBOX)Üret: sandbox'ta bir özellik ekletin, commit'leyin; sonra "bu özelliği bilerek boz" deyin. Denetle: bozulmayı revert ile geri aldırın ve uygulamanın eski hâline döndüğünü bizzat doğrulayın. (Geri dönüşü bir kez YAŞAMAK, on kez okumaktan değerlidir.)
8 · Kontrol soruları(1) Ne zaman commit atılır? (2) Revert ile reset farkı nedir, şüphede hangisi? (3) Riskli deneme neden branch'te yapılır?
9 · Mentor istemi
VibeUni Seviye 2 Ders 2.2'nin (git disiplini) hocası ol. Commit/branch/revert-reset'i
oyun kayıt noktası metaforuyla anlat. Bana 4 senaryo ver, her birinde hangi git
hamlesini seçeceğimi sor ve değerlendir. Sonunda 3 kontrol sorusu.
DERS 2.3 Kalite kapıları: build ve test
1 · TanımKapı = işin bir sonraki aşamaya geçmeden önce geçmek ZORUNDA olduğu mekanik kontrol: build (proje tutarlı mı derleniyor) ve testler (kurallar hâlâ sağlanıyor mu).
2 · İşlev ve amaçKapılar, denetimi kişisel gayretten çıkarıp mekanik zorunluluğa çevirir. Sizin gözünüz yorulur, kapı yorulmaz. "Geçti/geçmedi" cevabı tartışmasızdır — AI ile aranızdaki en objektif hakem.
3 · Nasıl yapılırSıralı kapı zinciri: değişiklik → build → (varsa) testler → kendi denemeniz → commit → yayın. Kural: commit'ten önce build; yayından önce hepsi. Kapıyı CLAUDE.md'ye yazın ("commit önerisinden önce build çalıştır ve sonucu göster"). Testleriniz yoksa: kritik akışlar için AI'a yazdırın — "bu projenin en kritik 3 davranışı için test yaz" iyi bir başlangıçtır.
4 · Ne ters gider + gerçek vaka
Gerçek vaka: Bir üründe hızlı kontrol aracı (tip denetimi) "her şey yolunda" dedi; ama tam build ancak yayın sırasında patladı — sorun, hızlı kontrolün hiç bakmadığı bir katmandaydı. Saatler kaybedildi. Ders: hızlı kontrol, tam build'in yerine geçmez. Yayına neyle çıkıyorsanız kapınız o olmalı.
Gerçek vaka (yayın doğrulaması): Bir yayında komut doğru çalıştı ama farkında olmadan YANLIŞ projeye yayın yapıldı — komut çıktısındaki "hangi projeye yayınlanıyor" satırı okunmamıştı. Ders: kapı sadece build değildir; yayın komutunun çıktısındaki hedef bilgisini okumak da bir kapıdır.
Çözüm kalıbı: kapılar atlanınca değil, atlanamaz yapılınca çalışır — kural dosyaya, alışkanlık zincire.
5 · AlternatiflerHer kaydetmede otomatik kapı koşturmak (hook — Seviye 3.2) manuel disiplinin gelişmişidir; oraya Seviye 3'te geleceksiniz.
6 · Denetim penceresiKırmızı bayraklar: "build'e gerek yok, küçük değişiklik" cümlesi (küçük değişiklikler de kırar) · test sayısının büyüyen projede hiç artmaması · "testleri geçti" beyanının çıktısız gelmesi. Kontrol istemi: "build ve test komutlarını çalıştır; çıktıları KISALTMADAN göster; geçmeyenleri tablo yap."
7 · Mini egzersiz (SANDBOX)Üret: sandbox'ta bir dosyayı bilerek bozdurun ("build'i kıracak küçük bir hata ekle"). Denetle: build'i çalıştırıp hatanın nasıl göründüğünü okuyun; sonra düzelttirin ve kapının yeşile dönüşünü izleyin. Kırmızı-ekranla ilk tanışma güvenli ortamda olsun.
8 · Kontrol soruları(1) Kapı zinciri hangi sırayla dizilir? (2) Hızlı kontrol neden tam build'in yerini tutmaz? (3) Yayın komutunda okunması şart olan satır hangisidir?
9 · Mentor istemi
VibeUni Seviye 2 Ders 2.3'ün (build/test kapıları) hocası ol. Kapı kavramını havaalanı
güvenlik kontrolü metaforuyla anlat. Bana örnek bir build hata çıktısı göster ve
panik yapmadan nasıl okuyacağımı öğret. Sonunda 3 kontrol sorusu.
DERS 2.4 Hata ayıklama döngüsü: kök neden vs yama
1 · TanımHata ayıklama = belirtiden (hata mesajı, yanlış davranış) kök nedene inip onu düzeltme süreci. Karşıtı: yama — belirtiyi örtüp nedeni yerinde bırakmak.
2 · İşlev ve amaçAI hızlı yama üretmekte ustadır; yönetilmezse "çalışana kadar dene" moduna girer ve her yama yeni bir hata doğurur (Seviye 1.6'daki kısır döngünün kaynağı). Sizin işiniz süreci kök-neden yönüne itmek.
3 · Nasıl yapılırDört adımlı döngü: (1) Belirtiyi eksiksiz ver: hata mesajını KIRPMADAN yapıştırın + "ne yapınca oluyor" tarifi. (2) Kök neden isteyin: "düzeltmeden önce kök nedeni bul ve bana teknik olmayan dille açıkla." (3) Açıklamayı anlayın: anlamadıysanız düzeltme onayı yok — "daha basit anlat" hakkınız sınırsız. (4) Düzeltme + doğrulama: hatayı yeniden tetikleyerek gerçekten gittiğini görün (ders 1.5 merdiveni).
4 · Ne ters gider + çözümüTuzak 1: "hata alıyorum, düzelt" (mesajsız) → AI körlemesine tahmin eder. Çözüm: mesaj + adım tarifi olmadan düzeltme istemeyin. Tuzak 2: hata gitti ama neden gittiğini kimse bilmiyor → aynı hata başka kılıkla döner. Çözüm: "ne bozuktu, ne değişti, niye bir daha olmaz?" üçlüsünü her düzeltmeden sonra sorun; ikna edici cevap yoksa iş bitmemiştir. Tuzak 3: üçüncü yama — ders 1.6 kuralı: oturumu tazeleyin.
5 · AlternatiflerFrontend/backend ayrımıyla ön-teşhis: hata ekranda mı (salon) veride/kayıtta mı (mutfak)? Bu tek soru bile aramayı yarıya indirir ve AI'a daha iyi başlangıç noktası verir.
6 · Denetim penceresiKırmızı bayraklar: açıklaması yapılamayan düzeltme ("bir şeyler değiştirdim, geçti") · düzeltmenin dokunduğu dosyaların hatayla görünür ilgisinin olmaması · aynı belirtinin farklı yerlerde tekrarlaması. İkinci-ajan denetimi (temiz oturum): "Şu hata şöyle düzeltilmiş: [özet]. Bu düzeltme kök neden mi yama mı? Aynı hatanın başka yoldan tekrar etme riskini değerlendir."
7 · Mini egzersiz (SANDBOX)Üret: "uygulamaya bulması orta zorlukta bir hata sakla" deyin (AI saklasın), sonra hatayı kullanıcı gibi bulun. Denetle: dört adımlı döngüyü tam uygulayın; 3. adımdaki açıklamayı bir arkadaşınıza anlatabilecek kadar anlayın.
8 · Kontrol soruları(1) Kök neden ile yama farkı nedir? (2) Hata bildirirken iki zorunlu bileşen nedir? (3) Düzeltme sonrası üçlü soru nedir?
9 · Mentor istemi
VibeUni Seviye 2 Ders 2.4'ün (hata ayıklama döngüsü) hocası ol. Kök neden/yama farkını
"su sızıntısı + kova" metaforuyla anlat. Bana örnek bir hata senaryosu yaşat: ben
kullanıcıyım, sen AI'sın; dört adımı doğru işletip işletmediğimi değerlendir. 3 kontrol sorusu.
DERS 2.5 Geri alınamaz komutlar: kırmızı bölge
1 · TanımKırmızı bölge = git'in sigortasının İŞLEMEDİĞİ işlemler: canlı veritabanı müdahaleleri (migration, silme, sıfırlama), dosya sisteminde kalıcı silme, dış dünyaya giden geri çağrılamaz eylemler (e-posta, ödeme).
2 · İşlev ve amaçDers 1.7'de sınırların haritasını çizdiniz; burada en tehlikeli bölgenin çalışma protokolünü öğreniyorsunuz. Fark şu: kod hatası tarihçeden döner, veri hatası dönmez — çünkü veri, git'in değil veritabanının içindedir.
3 · Nasıl yapılır — kırmızı bölge protokolü(1) Önce yedek: "bu işlemden önce veritabanının yedeğini nasıl alırım, komutunu hazırla" — yedeğin ALINDIĞINI görmeden devam yok. (2) Önce prova: işlem önce deneme kopyasında (preview/dev veritabanı, Neon'da dal kopyası) çalıştırılır, sonuç kontrol edilir. (3) Ekleyerek ilerle: yapı değişikliklerinde "ekle" güvenli, "sil/değiştir" tehlikelidir — sütun silmek yerine önce yeni sütunu ekle, veriyi taşı, eskiyi ancak her şey doğrulanınca kaldır. (4) Son adım elle: canlıdaki nihai komutu AI değil siz tetiklersiniz — bilerek, okuyarak.
4 · Ne ters gider + gerçek vaka
Gerçek vaka: Ders 1.7'deki veri kaybı vakasının perde arkası: şema uyuşmazlığında araç "sıfırlayıp yeniden kurayım mı?" diye sordu, hızlı onay verildi, canlı tablolar boşaldı. Üç koruma da atlanmıştı: yedek yok, prova yok, son adım elde değil. Tek bir protokol adımı bile faciayı önlerdi.
Çözüm sistemik: bu protokolü projenizin CLAUDE.md'sine yazın: "Veritabanı yapısını değiştiren hiçbir komutu doğrudan çalıştırma; önce yedek + prova planı sun."
5 · Alternatifler"Hiç dokunmayalım" da yanlış: ürün büyüdükçe şema değişecek. Alternatif yol, korkmak değil ritüelleştirmektir — protokol varsa kırmızı bölge rutin işe döner.
6 · Denetim penceresiOnay öncesi dört soru (ders 1.7'deki istemin veritabanı versiyonu): "Bu işlem hangi tablolara dokunuyor? Geri alınabilir mi? Yedek nerede? Provası yapıldı mı?" Dördünden biri cevapsızsa onay yok. Kırmızı bayrak kelimeleri: force, reset, drop, truncate, delete from (koşulsuz).
7 · Mini egzersiz (SANDBOX)Üret: sandbox için "örnek bir veritabanı şema değişikliği senaryosu yaz: bir sütunun adını değiştireceğiz; güvenli ve tehlikeli yolu karşılaştır" isteyin. Denetle: AI'ın güvenli yolunda 4 protokol adımının hepsi var mı? Eksik olanı SİZ yakalayın.
8 · Kontrol soruları(1) Kod hatası ile veri hatası neden farklı ligdedir? (2) Kırmızı bölge protokolünün 4 adımı nedir? (3) "Ekleyerek ilerle" ne demektir?
9 · Mentor istemi
VibeUni Seviye 2 Ders 2.5'in (geri alınamaz komutlar) hocası ol. Kırmızı bölge
protokolünü bana bir ameliyat kontrol listesi ciddiyetiyle anlat. Sonra 5 komut örneği
göster; hangileri kırmızı bölge, tek tek karar vereyim. Sonunda 3 kontrol sorusu.
DERS 2.6 Env ve secret: şifrelerin evi
1 · TanımOrtam değişkeni = ortama göre değişen ayar; secret = şifre değerindeki ayarlar (API anahtarları, veritabanı bağlantısı). Evleri: yerelde .env dosyası (repoya GİRMEZ), canlıda barındırma panelinin ortam-değişkenleri bölümü.
2 · İşlev ve amaçTek cümlelik yasa: koda yazılan şifre, çalınmış şifredir. Repo bir gün paylaşılır, yedeklenir, sızar — içindeki anahtar da onunla gezer. Anahtarın kod dışında yaşaması, sızıntıyı yapısal olarak önler.
3 · Nasıl yapılır(1) Proje kurulurken .env'nin repo-dışı listede (.gitignore) olduğunu doğrulatın: "'.env' dosyası git'e girmiyor, doğru mu? Kanıtla." (2) Yeni bir hizmet bağlanırken (Resend, ödeme...) anahtarı .env'ye siz yapıştırın — sohbete yapıştırmak zorunda değilsiniz; "anahtarı .env'ye NE adla koyacağımı söyle, ben koyarım" deyin. (3) Canlıya çıkarken aynı değişkenleri barındırma paneline girin — "canlı için hangi ortam değişkenlerini panele girmem gerekiyor, liste çıkar" isteyin ve listeyi tek oturuşta girin.
4 · Ne ters gider + çözümüKaza 1: anahtar yanlışlıkla koda/repoya girdi. Çözüm: sadece silmek YETMEZ (tarihçede durur) — anahtarı hizmet panelinden iptal edip (rotate) yenisini alın; sonra dosyadan temizleyin. Kaza 2: "yerelde çalışıyor, canlıda çalışmıyor" — klasik sebep: değişken panele girilmemiş. Çözüm: canlı hata + "environment variable" kelimesini görünce önce panel kontrolü. Kaza 3: boş değer — panel arayüzü bazen değeri sessizce boş kaydeder; girdikten sonra kaydedilen değerin gerçekten dolu olduğunu panelden teyit edin.
5 · AlternatiflerTakım büyüyünce secret yöneticisi araçlar devreye girer; tek kişilik üründe .env + panel ikilisi yeterli ve standarttır.
6 · Denetim penceresiPeriyodik tarama istemi: "Bu repoda koda gömülü anahtar/şifre/bağlantı adresi var mı tara; şüpheli her bulguyu dosya adıyla listele." Kırmızı bayraklar: kod içinde sk-, key=, uzun rastgele karakter dizileri · .env'nin repoda görünmesi. Bu tarama, mezuniyet görevinizin de parçası.
7 · Mini egzersiz (KENDİ-PROJEN)Denetle (bu ders üretmeden denetler): mevcut bir projenizde 6. bölümdeki tarama istemini çalıştırın. Bulgu çıkarsa: anahtarı panelden yenileyin, dosyayı temizletin, .gitignore'u doğrulatın — üç adımı sırasıyla.
8 · Kontrol soruları(1) "Koda yazılan şifre çalınmış şifredir" — neden? (2) Repoya sızan anahtarda ilk hamle silmek midir, değilse nedir? (3) "Yerelde çalışıyor canlıda çalışmıyor"un klasik sebebi?
9 · Mentor istemi
VibeUni Seviye 2 Ders 2.6'nın (env/secret) hocası ol. Secret kavramını "ev anahtarını
paspasın altına yazmak" metaforuyla anlat. Bana bir sızıntı senaryosu ver; doğru
kurtarma sırasını kurayım, değerlendir. Sonunda 3 kontrol sorusu.
DERS 2.7 Mimari okuma ve denetleme: projenin haritası
1 · TanımMimari = projenin yapısal düzeni: klasörler (odalar), katmanlar (ekran ↔ iş mantığı ↔ veri) ve veri akışı (tesisat). Mimari okumak = kod okumadan bu düzeni görebilmek.
2 · İşlev ve amaçMezun profilinin 2. yetkinliği tam olarak budur: "yapı doğru kurulmuş mu?" sorusuna yönlendirme almadan cevap verebilmek. Bina sahibi tuğla örmez ama kat planına bakıp "banyo neden mutfağın içinde?" diyebilir. Kötü mimari bugün çalışır — faturası, her yeni özelliğin gitgide zorlaşması olarak sonra gelir.
3 · Nasıl yapılırHarita çıkarma istemi (her projede işe yarar):
Bu projenin mimari haritasını teknik olmayan dille çıkar:
1) Klasör ağacı (2 seviye) — her klasör tek cümleyle ne işe yarıyor?
2) Bir kullanıcı işlemi örneğinde veri akışı: ekrandan veritabanına hangi duraklardan geçiyor?
3) Projenin "tek doğru yeri" olan şeyler nerede: ayarlar, veritabanı şeması, ortak bileşenler?
Sonra sağlık kontrol listesi — kod bilmeden bakılabilen 5 işaret: (1) Benzer şeyler bir arada mı? (ekran dosyaları bir yerde, veri işleri bir yerde — yoksa her yerde her şey?) (2) Dev dosya var mı? ("en büyük 5 dosyayı satır sayısıyla listele" — bir dosya diğerlerinin 5-10 katıysa, her iş oraya yığılıyor demektir.) (3) Aynı bilgi iki yerde mi? (aynı kural/metin/ayar kopyala-yapıştırla çoğalmışsa: birini değiştirince öbürü unutulur.) (4) Şema okunaklı mı? (veritabanı şema dosyasını açın — tablo adları işinizin dilini konuşuyor mu?) (5) Yeni özellik nereye? ("yarın X özelliği eklesek hangi dosyalar değişirdi?" — cevap "her yerden biraz" ise mimari kokuyor.)
4 · Ne ters gider + çözümüVibe coding'in doğal sürüklenmesi: her istem "çalışan en kısa yolu" ekler; on istem sonra yapı spagettiye döner. Çözüm: periyodik mimari bakımı — ayda bir harita çıkarıp 5 işareti kontrol edin; sorun görünce "davranışı DEĞİŞTİRMEDEN şu ikilemeyi tekle / şu dev dosyayı böl" diye hedefli iş isteyin (buna refactor denir: dışarıdan aynı, içeriden düzenli).
5 · AlternatiflerKendi kontrolünüzün ölçekli hâli: çok-boyutlu denetim kampanyası (Seviye 4.5) — birden çok ajanın projeyi farklı gözlüklerle taraması. Bu ders o kampanyanın el fenerli versiyonudur.
6 · Denetim penceresiİkinci-ajan mimari denetimi (temiz oturumda): "Bu projenin mimarisini bağımsız denetle: 5 sağlık işaretine göre puan ver (her biri 1-5), en riskli 3 bulguyu 'sorun → günlük hayattaki bedeli → önerilen düzeltme' formatında yaz. Hiçbir şeyi değiştirme." — Puanlamayı sizin yerinize düşünmesin diye kendi puanınızı ÖNCE verin, sonra karşılaştırın.
7 · Mini egzersiz (KENDİ-PROJEN)Üret: en aktif projenizin haritasını çıkartın. Denetle: 5 işareti kendiniz puanlayın, sonra ikinci-ajan denetimiyle karşılaştırın. En az bir bulguyu "hedefli düzeltme işi" olarak tarif edin (yapmasanız bile tarif edin — tarif etmek, denetim yetkinliğinin kendisidir).
8 · Kontrol soruları(1) Kod bilmeden bakılabilen 5 sağlık işareti nedir? (2) "Yeni özellik nereye eklenirdi?" sorusu neyi ölçer? (3) Refactor nedir ve nesi değişmez?
9 · Mentor istemi
VibeUni Seviye 2 Ders 2.7'nin (mimari okuma) hocası ol. Mimarlık metaforuyla katman
kavramını anlat. Bana uydurma bir proje klasör ağacı göster: içine 3 mimari koku sakla,
5 işaret listesiyle bulmamı iste. Sonunda 3 kontrol sorusu.
Seviye 2 Mezuniyeti
Görev (KENDİ-PROJEN): Düşük riskli bir gerçek projenizde uçtan uca teslim: CLAUDE.md yazın (2.1) → küçük bir gerçek görevi branch'te yaptırın (2.2) → kapılardan geçirin (2.3) → çıkan bir hatayı kök-neden döngüsüyle çözdürün (2.4) → secret taraması koşturun (2.6) → mimari haritayı çıkarıp 5 işareti puanlayın (2.7) → merge + commit. Zincir tamamsa mezunsunuz.
Seviye-sonu mentor istemi (kümülatif):
VibeUni Seviye 2'nin bitirme sınavını yap. Yedi dersin kontrol sorularından karışık 7
soru sor; ayrıca Seviye 1'in kontrol sorularından rastgele 3 soru ekle (kümülatif
tekrar). Cevaplarımı değerlendir, zayıf derslerimi söyle.
Sonraki seviye: seviye-3-sistem.md — tekrarı otomatiğe bağlamak.