<hr/>

<h2>
    Mimarisi
</h2>

<p>Sistem beş bölümden oluşmaktadır:</p>
<ol>
    <li><p><strong><code>investigate</code> — yönlendirici.</strong> Gerçekten çalıştırdığınız komut budur. Hata bağlamını alır, dört uzmana paralel olarak yönlendirir, bulgularını bekler, her şeyi sentezler ve düzeltmeyi üretir.</p></li>
    <li><p><strong><code>sentry-fetcher</code> — hata yorumlayıcısı.</strong> Sentry API'sine erişir, sorunu alır, stack trace'i ayrıştırır ve yapılandırılmış bulgular döner.</p></li>
    <li><p><strong><code>telescope-reader</code> — istek denetleyicisi.</strong> Laravel Telescope'dan başarısız olan isteği bulmak için sorgular — her SQL sorgusunu, her birinin aldıkları süreyi, kaydedilen istisnaları, herhangi bir N+1 desenini kontrol eder.</p></li>
    <li><p><strong><code>codebase-analyst</code> — kod izleyici.</strong> Yönlendirme, kontrolör metodu, etkileşimde bulunduğu her hizmet ve model, migration dosyası okur ve stack trace'ten gelen belirli dosya ve satıra odaklanarak kodun yanlış yapabileceği varsayımları belirler.</p></li>
    <li><p><strong><code>git-detective</code> — geçmiş araştırmacısı.</strong> Hata satırındaki <code>git blame</code> komutunu çalıştırır, en son dokunan commit'i gösterir, o commit'i karşılaştırır ve son değişikliğin regresyon oluşturup oluşturmadığını kontrol eder.</p></li>
</ol>

<p>Yönlendirici, paralel olarak tüm dördünü çalıştırır. İşlemler tamamlandığında, bulguları birbirleriyle karşılaştırır ve bir tanı ve minimal bir kod düzeltmesi üretir.</p>

<hr/>

<h2>
    Yönlendirici: <code>investigate</code>
</h2>

<p>Bu, her şeyi başlatan Claude Code komutudur. Şu şekilde çalıştırırsınız:</p>

<div class="highlight js-code-highlight">
    <pre class="highlight shell"><code># Minimal çağrı

<p>Yönlendiricinin görevi koordinasyon, araştırma değil. Komut, şunları belirtilmek üzere talimat verir:</p>

<div class="highlight js-code-highlight">
    <pre class="highlight plaintext"><code>## Aşama 1 — Tüm 4 uzmanın KAYGISIYLA PARALEL İŞLETİLMESİ

Dört görevi eşzamanlı başlatın. Birinin bitmesini beklemeden diğerini başlatın.

• sentry-fetcher: sorun ID’sini, uç noktayı ve zaman dilimini geçirin

• telescope-reader: uç noktayı, zaman dilimini ve Telescope URL’sini geçirin

• codebase-analyst: uç noktayı, controller@method’ı, dosya ve satırı geçirin

• git-detective: dosya yolunu, satır numarasını ve bağlantılı dosyaları geçirin
  

  Paralel yürütme önemlidir. Her bir yardımcı gerçek çalışmayı yapar — API çağrıları, dosya okumaları, git komutları. Bunları sıralı çalıştırmak yavaş olur. Paralel çalıştırmak, toplam sürenin yaklaşık olarak en yavaş olan ajan kadar olmasını sağlar, tüm dördünün toplamı değil.

  ---

  Sentry Fetcher
  

  Bu ajan yalnızca bir şeyi yapar: Sentry API’si ile konuşur ve yapılandırılmış bulguları döner.

  SENTRY_AUTH_TOKEN, SENTRY_ORG ve SENTRY_PROJECT değerlerini .env dosyanızdan okur ve Sentry REST API’sini erişir:

  # Eğer ona direkt bir sorun ID'si verirseniz:
  GET https://sentry.io/api/0/organizations//issues//
  
  
  Sonra her zaman en son olayı alır:
  GET https://sentry.io/api/0/organizations//issues//events/latest/
  

  <p>Yapılandırılmış bir blok döner; bu da yönlendiricinin üzerinde düşünmesini sağlar:</p>
  
  <div class="highlight js-code-highlight">
      <pre class="highlight plaintext"><code>SENTRY BULGULARI

  ===============
  Sorun ID’si: CADE-412
  Başlık: TypeError: Attempt to read property “id” on null
  Suçlu: App\Services\TournamentService::joinTournament (satır 87)
  İlk Görülme: 2026-02-28 14:31 UTC
  Son Görülme: 2026-03-01 09:12 UTC
  Toplam Oluşum Sayısı: 34
  Etkilenen Kullanıcılar: 12

  STACK TRACE (en ilgili çerçeveler):

  • Dosya: app/Services/TournamentService.php
  • Satır: 87
  • Metot: joinTournament
  • Kod: $entry->tournament->prize_pool

  BREADCRUMBS (çökmeye kadar son 5):

  1. GET /api/tournaments/412 – 200
  2. POST /api/tournaments/join – istek alındı
  3. Doğrulama geçti
  4. TournamentService::joinTournament çağrıldı
  5. Entry::create başarıyla tamamlandı — sonra çökme

  KÖK ŞÜPHE:
  $entry->tournament ilişkisi null döndü — eager load muhtemelen eksik.
  

  <p>Bu, diğerlerine nereye bakmaları gerektiğini söyleyen ajandır. Ortaya çıkardığı stack trace, <code>codebase-analyst</code> ve <code>git-detective</code> ile geçilir, böylece hangi dosya ve satıra odaklanacaklarını bilirler.</p>
  
  <hr/>
  
  <h2>
      Telescope Reader
  </h2>
  
  <p>Bu ajan, Laravel Telescope'un iç API'si ile sorgular yaparak başarısız olan isteği yeniden inşa eder. Görünürde <code>/telescope-api/requests</code>, <code>/telescope-api/queries</code>, ve <code>/telescope-api/exceptions</code> yollarını kullanır - ama buna doğrudan erişim sağlamazsınız. Sadece şu verileri geri alırsınız:</p>
  
  <div class="highlight js-code-highlight">
      <pre class="highlight plaintext"><code>TELESCOPE BULGULARI

  ==================
  Eşleşen İstek Giriş ID’si: 01HX7K2…
  Uç Nokta: POST /api/tournaments/join
  Zaman Damgası: 2026-02-28 14:31:22 UTC
  Yanıt Durumu: 500
  Yanıt Süresi: 1,847ms

  ÇALIŞTIRILAN SORGULAR:

  1. SELECT * FROM tournaments WHERE id = ? — 2ms
  2. SELECT * FROM entries WHERE tournament_id = ? — 3ms
  3. SELECT * FROM entries WHERE tournament_id = ? — 3ms ← tekrar
  4. SELECT * FROM entries WHERE tournament_id = ? — 3ms ← tekrar
     … (toplam 23 kez tekrar etti)

  N+1 UYARISI: Evet
  Aynı sorgu 26 kez farklı bindings ile tekrarlandı.

  KÖK ŞÜPHE:
  Girişler üzerinde eksik eager load. Turnuva ilişkisi Entry modelinde hiç yüklenmedi — her erişim ayrı bir sorgu tetikledi.
  

  <p>Telescope üretimde devre dışı bırakıldığında (performans için yaygın bir durum), ajan bunu açıkça belirtir ve varsayımlar yapmadan boş bulgular döner — bu doğru bir davranıştır.</p>
  
  <hr/>
  
  <h2>
      Codebase Analyst
  </h2>
  
  <p>Bu ajan, gerçek kodunuzu okur. Yapıyı tahmin etmez — dosyaları açar.</p>
  
  <p>Verilen uç nokta, kontrolör ve hata satırı ile:</p>
  <ol>
      <li><p>routes/api.php dosyasını okuyarak yönlendirme haritasını doğrular.</p></li>
      <li><p>Tüm kontrolör dosyasını okur ve etkili metoda odaklanır.</p></li>
      <li><p>Metodun çağırdığı her servis, repository ve yardımcıyı izler.</p></li>
      <li><p>İlgili her modeli okur — ilişkiler, castler, erişimciler.</p></li>
      <li><p>Ana tabloların migration dosyasını okur, sütun türlerini ve nullable kısıtlamalarını kontrol eder.</p></li>
      <li><p>Hata satırına doğrudan geçer ve 20 satır yukarıdan ve aşağıdan okur.</p></li>
  </ol>
  
  <p>Sonuç, yönlendiriciye kodun neye dayandığını ve nerede yanlış olabileceğini tam olarak söyler:</p>
  
  <div class="highlight js-code-highlight">
      <pre class="highlight plaintext"><code>KODDA BULGULAR

  =================
  Yönlendirme doğrulandı: POST /api/tournaments/join → TournamentController@join

  KOD AKIŞI ÖZETİ:

  1. İstek, TournamentController@join’yi vurur.
  2. TournamentJoinRequest, player_id ve tournament_id değerlerini doğrular.
  3. TournamentService::joinTournament($player, $tournamentId) çağrılır.
  4. Entry::create() kaydı kaydeder.
  5. $entry->tournament->prize_pool’a erişir — HERhangi bir eager load yoktur.

  SORUNLU SATIR:

  • Dosya: app/Services/TournamentService.php
  • Satır: 87
  • Kod: $wallet->credit($entry->tournament->prize_pool * 0.1);
  • Ne varsayıyor: $entry->tournament her zaman yüklüdür.
  • Bu varsayımın başarısız olabileceği durum: Giriş yalnızca Entry::create() ile oluşturuldu — Eloquent, yeni oluşturulan modellerde otomatik olarak ilişkileri yüklemiyor.

  KÖK ŞÜPHE:
  $entry->tournament null çünkü ilişki, Entry::create()’den sonra hiç eager load edilmedi. Satır 87’den önce $entry->load(‘tournament’) çağırın.
  

  <p>Buradaki temel tasarım kararı, bu ajanın hiçbir zaman düzeltmeyi yazmamasıdır. Sorunu tanımlar ve yönlendiriciye düzeltmenin nerede yapılması gerektiğini kesin olarak belirtir. Yönlendirici değişikliği yapar. Bu ayrım, her ajanın dikkatli kalmasını sağlıyor ve sistemi anlamayı kolaylaştırıyor.</p>
  
  <hr/>
  
  <h2>
      Git Detective
  </h2>
  
  <p>Bu ajan, git geçmişinizi araştırır. Altında <code>git log</code>, <code>git blame</code>, <code>git show</code> ve <code>git diff</code> çalıştırır — ama bunların hiçbiriyle doğrudan uğraşmazsınız. Size bir dosya yolu ve satır numarası verilir ve esasen şu soruya yanıt verir: <em>bu her zaman bozuk muydu, yoksa yakınlarda bir şey değişti mi?</em> Bu ayrım, nasıl düzeleceğini ve neyin acil olduğunu belirlemede önemlidir.</p>
  
  <p>İşte döndüreceği bilgiler:</p>
  
  <div class="highlight js-code-highlight">
      <pre class="highlight plaintext"><code>GIT BULGULARI

  ============
  Etkilenen Dosya: app/Services/TournamentService.php
  Son Değişiklik: 2026-02-26
  Commit Hash: a3f91c2
  Commit Mesajı: “feat: add referral credit on tournament join”

  HATA SATIRINDA BİRİT:

  • Satır 87, a3f91c2 commit’inde son dokunan
  • Commit tarihi: 2026-02-26
  • Değişiklik: $entry->tournament->prize_pool kullanarak cüzdan kredi mantığı eklendi.
    İlişkiye erişim bu değişiklikte eklendi. Eager load eklenmedi.

  AYNİ COMMIT’TE BAĞLANTILI DOSYA DEĞİŞİKLİKLERİ:

  • Entry.php: referral_bonus sütun erişimi eklendi — ilişki değişiklikleri yok
    

    ---

    Aşama 3: Sentez
    

    Tüm dört ajandan gelen yanıtlar geldikten sonra, yönlendirici bunları karşılaştırır:

    • Sentry stack trace, codebase analyst’ın işaret ettiği aynı satıra mı işaret ediyor? ✓
    • Telescope, hatayı açıklayan bir desen gösteriyor mu (N+1, yavaş sorgu, kayıp veri)? ✓
    • Git, sorunu oluşturan yakın bir commit gösteriyor mu? ✓
    • En olası kök neden nedir?

    KÖK NEDEN TANI
    ====================
    Ne oldu: $entry->tournament satırı 87'de null döndü.
    Neden oldu: Entry::create() ilişkileri otomatik yüklemez. Turnuva
    ilişkisi, yüklenmeden hemen sonra erişildi.
    Bunu tetikleyen: a3f91c2 commit'i (26 Şubat) prize_pool erişimini ekledi,
    ancak $entry->load('tournament') veya Entry::create()->load('tournament') çağrısını eklemedi.
    Güven düzeyi: Yüksek
    

    ---

    Aşama 4: Düzeltme
    

    Yönlendirici minimal değişikliği yapar:

    // Önce (TournamentService.php satır 87)
    $wallet->credit($entry->tournament->prize_pool * 0.1);
    
    
    // Sonra
    $entry->load('tournament');
    $wallet->credit($entry->tournament->prize_pool * 0.1);
    

    <p>Ve tam çıktıyı teslim eder:</p>
    
    <div class="highlight js-code-highlight">
        <pre class="highlight plaintext"><code>ARAŞTIRMA TAMAM

    ======================

    KÖK NEDEN:
    Entry::create(), Eloquent ilişkilerini otomatik yüklemez.
    Referans kredisi özelliği, a3f91c2’de $entry->tournament erişimini ekledi
    ilk olarak yüklenmeden, bu durum 34 istekte, 12 kullanıcıda null özelliği erişimine neden oldu.

    KANIT:

    • Sentry: Satır 87’de TypeError, 34 oluşum, 12 etkilenen kullanıcı
    • Telescope: N+1 deseni tespit edildi, aynı istekte 26 tekrarlanan sorgu
    • Kod: Entry::create() sonrası turnuva ilişkisi erişiminden önce eager load yok
    • Git: a3f91c2’de (26 Şubat) — “feat: turnuva katılımında referans kredisi ekle”

    DEĞİŞİKLİK YAPILDI:

    • Dosya: app/Services/TournamentService.php
    • Metot: joinTournament
    • Ne değişti: $entry->load(‘tournament’) eklenerek prize_pool erişiminden önce

    İNCELEME KONTROL LİSTESİ:

    • [x] Düzeltme, çöküşün neden olduğu null/kenar durumunu ele alıyor mu?
    • [ ] Bunları kapsayan bir test var mı?
    • [ ] Bu düzeltme bir migration veya yapılandırma değişikliği gerektiriyor mu?
    • [x] Zaman kaybı olmadan yayına alınması güvenli mi?

    İNCELEME NASIL YAPILIR:
    Çalıştır: git diff
    Daha sonra memnun kaldığınızda Forge üzerinden dağıtım yapın.
    

    <p>Hiçbir şey taahhüt edilmez. Hiçbir şey gönderilmez. Hiçbir şey dağıtılmaz. Sistem, düzeltmeyi gözden geçirmem için benimle paylaşır — bu, yönlendirici isteminin katı bir kuralıdır. Ajanslar araştırır ve önerir. Ben karar veririm.</p>
    
    <hr/>
    
    <h2>
        Bu Ne Değiştirir?
    </h2>
    
    <p>Eski iş akışı sıralıydı: Sentry → kod → veritabanı → git → Telescope → hipotez → düzeltme. Her adım bir öncekini bekliyordu. Herhangi bir zamanda tüm bu bağlamları tutmanın zihinsel yükü gerçektir.</p>
    
    <p>Yeni iş akışı paraleldir. Dört ajan eş zamanlı araştırma yapar. Yönlendirici sentezler. Tanı, bir fark ve bir kontrol listesi alıyorum, bir dakikadan kısa sürede.</p>
    
    <p>Daha önemlisi, çıktı <em>katı</em> değil, <em>düşünülen</em> bir yanıttır. Yönlendirici, bana dört kaynaktan ham veriler göstermiyor — onları karşılaştırıyor, nerede aynı olduklarını ve nerede çelişki olduğunu belirleyip değerlendirebileceğim bir hipotez oluşturuyor. Bu, bilgi toplayan bir araç ile düşünce üreten bir sistem arasındaki farktır.</p>
    
    <hr/>
    
    <h2>
        Sırada Ne Var?
    </h2>
    
    <p>Sonraki evrim, bu ajanların bir hatada söz konusu olan belirli veritabanı kayıtlarına erişim sağlamasıdır. Şu anda yalnızca kodu, git geçmişini ve Sentry hatasını anlıyorlar — ancak çökme anında spesifik kaydın neye benzediğini bilmiyorlar.</p>
    
    <p>Bir projeyi sürdürdüğüm bir MCP sunucusu inşa ediyorum; bu, ajansların inceleme sırasında doğrudan veritabanına sorgu yapmalarını sağlayacak — kayıt, işlem geçmişi, eşleşme durumu alacak. Bir ajan, hem hatalı kodu hem de işlemekte olduğu verileri görebildiğinde tanı oldukça daha hassas hale gelir.</p>
    
    <p>Bir sonraki yazının konusu bu olacak.</p>
    
    <hr/>
    
    <h2>
        İstemci Dosyaları
    </h2>
    
    <p>Claude Code projeniz için klasör yapısı şöyle olacaktır:</p>
    
    <div class="highlight js-code-highlight">
        <pre class="highlight plaintext"><code>your-laravel-app/

    ├── .claude/
    │ ├── commands/
    │ │ └── investigate.md ← çalıştırdığınız komut
    │ └── agents/
    │ ├── sentry-fetcher.md
    │ ├── telescope-reader.md
    │ ├── codebase-analyst.md
    │ └── git-detective.md
    

    <p>Tek gerekli <code>.env</code> ayarı <code>SENTRY_AUTH_TOKEN</code>, <code>SENTRY_ORG</code> ve <code>SENTRY_PROJECT</code>'tür — muhtemelen zaten Sentry kullanıyorsanız bunları almışsınızdır.</p>
    
    <hr/>
    
    <h3>
        📋 <code>.claude/commands/investigate.md</code>
    </h3>
    
    <div class="highlight js-code-highlight">
        <pre class="highlight markdown"><code><span class="gh"># Üretim Hatasını Araştır</span>

    Siz, bir senior Laravel geliştiricisiniz ve bir üretim hata araştırmasının yönlendiricisiniz.
    Göreviniz, 4 uzman alt ajanın koordinasyonunu sağlamak, bulgularını sentezlemek ve tek bir gözden geçirilecek kod değişikliğini üretmektir.
    

    
    ## Geliştiriciden alacağınız girdi
    – Hata mesajı ve/veya Sentry sorun ID
    – Etkilenen uç nokta (örneğin POST /api/orders)
    – Biliniyorsa kontrolör@metot (örneğin App\Http\Controllers\OrderController@store)
    – Hatanın başladığı tahmini zaman

    Bu girdilerden herhangi biri eksikse, bulgular üzerine hangi bilgileri çıkararak soruyorsanız sorabilirsiniz.
    

    
    ## Aşama 1 — Tüm 4 uzmanın KAYGISIYLA PARALEL İŞLETİLMESİ

    Dört görevi eşzamanlı başlatın. Birinin bitmesini beklemeden diğerini başlatın.

    ### Görev 1 → sentry-fetcher ajanı
    Geçin:
    – Hata mesajı veya sorun ID’si
    – Uç nokta
    – Zaman dilimi

    ### Görev 2 → telescope-reader ajanı
    Geçin:
    – Etkilenen uç nokta
    – Zaman dilimi
    – Telescope URL’si: .env’den APP_URL okuyun ve /telescope ile ekleyin

    ### Görev 3 → codebase-analyst ajanı
    Geçin:
    – Uç nokta
    – Stack trace ile kontrolör@metot
    – Belirtilen dosya ve satır numarası (bu bilgi yoksa Sentry bulgularından çıkartabilirsiniz.
    Ancak görevleri eş zamanlı yürüttüğünüzden, geliştiricinin verdiği ilk bilgiyi kullanın — Sentry sonuçları geldikten sonra bu ajanı yeniden çalıştırabilirsiniz.)

    ### Görev 4 → git-detective ajanı
    Geçin:
    – Stack trace’ten dosya yolu
    – Satır numarası
    – Şüpheli herhangi bir bağlantılı dosya (kontrolör, model, servis)
    

    
    ## Aşama 2 — Tüm 4 ajanın geri dönmesini bekleyin

    Tüm bulgular geldikten sonra, her birini dikkatlice okuyun.
    

    
    ## Aşama 3 — Sentezleyin

    Dört bulguyu karşılaştırın:
    1. Sentry stack trace, codebase analyst’ın işaret ettiği aynı satıra mı işaret ediyor?
    2. Telescope, hatayı açıklayan yavaş veya eksik bir sorgu gösteriyor mu?
    3. Git, sorunu oluşturan yakın bir commit gösteriyor mu?
    4. En olası kök neden nedir?

    Açık bir İngilizce tanı yazın:

    KÖK NEDEN TANI

    Ne oldu:
    Neden oldu:
    Bunu tetikleyen (yakın dağıtım? kötü girdi? kayıp veri?):
    Güven düzeyi: Yüksek / Orta / Düşük
    

    
    ## Aşama 4 — Düzeltmeyi üretin

    Şimdi gerçek kod değişikliğini yapın:
    
    1. Belirlenen dosyayı açın
    2. Kök nedeni düzeltmek için gereken minimal değişikliği yapın
    3. Alakalı olmayan kodları yeniden yapılandırmayın
    4. Gerekmedikçe 1-3’ten fazla dosyayı değiştirmeyin

    Tanı ile ilgili düzeltme uygulamak için yaygın düzeltme örüntüleri:
    – Null erişim → null kontrol ekleyin veya optional chaining (?->) kullanın veya uygun hata işleme ile findOrFail ekleyin
    – Eksik eager load → sorguya with(‘relation’) ekleyin
    – N+1 sorgu → sorguyu eager load uygulayacak şekilde yeniden yapılandırın
    – Tür uyuşmazlığı → modelde cast ekleyin veya kullanım noktasında açık dönüştürme yapın
    – Eksik doğrulama → Form Talep dosyasına kural ekleyin
    – Yarış durumu / eksik veritabanı kısıtlaması → veritabanı düzeyinde koruma ekleyin
    

    
    ## Aşama 5 — Çıktınızı teslim edin

    Bunu geliştiriciye sunun:

    ARAŞTIRMA TAMAM

    KÖK NEDEN:
    (2-3 cümle, açık İngilizce)

    KANIT:
    – Sentry: (bir ana bulgu)
    – Telescope: (bir ana bulgu)
    – Kod: (bir ana bulgu)
    – Git: (bir ana bulgu veya “son değişiklik yok”)

    YAPILAN DEĞİŞİKLİK:
    – Dosya:
    – Metot:
    – Ne değişti: (açık İngilizce, diff değil)

    İNCELEME KONTROL LİSTESİ:
    – [ ] Düzeltme, çökmesine neden olan null/kenar durumunu ele alıyor mu?
    – [ ] Kapsanması gereken bir test var mı?
    – [ ] Bu düzeltme bir migration veya yapılandırma değişikliği gerektiriyor mu?
    – [ ] Zaman kaybı olmadan yayına alınması güvenli mi?

    İNCELEME NASIL YAPILIR:
    Çalıştır: git diff
    Daha sonra memnun kaldığınızda Forge üzerinden dağıtım yapın.
    

    
    ## Önemli kurallar
    – Hiçbir şeyi taahhüt etmeyin
    – Hiçbir şeyi Forge dağıtımlarına tetiklemeyin
    – Hiçbir şeyi GitHub’a itmeyin
    – Sadece minimal düzeltmeyi yapın — geri kalanını geliştiriciye bırakın
    – Düzeltme konusunda kendinize güvenmezseniz (Düşük güven düzeyi), bunu açıkça belirtin ve nedenini açıklayın
    – Hata, migration gerektiriyorsa, gerekli migration’ın ne olduğunu açıklayın ama çalıştırmayın
    

    <hr/>
    
    <h3>
        🔍 <code>.claude/agents/sentry-fetcher.md</code>
    </h3>
    
    <div class="highlight js-code-highlight">
        <pre class="highlight markdown"><code><span class="gh"># Sentry Fetcher Ajanı</span>

    Sentry API’sinden hata verilerini alır ve yorumlar.
    Tek bir şeyi yaparsınız: Sentry sorun detaylarını alır ve yapılandırılmış bulgular döner.
    Kod okumazsınız. Git kontrolü yapmazsınız. Veritabanıyla ilgilenmezsiniz.
    

    
    ## Kimlik Doğrulama
    – Projeye ait SENTRY_AUTH_TOKEN‘u .env dosyasından okuyun
    – Temel URL: https://sentry.io/api/0/
    – Başlık ayarı: Authorization: Bearer
    

    
    ## Size gelen (ana ajandan)
    – Bir hata mesajı veya Sentry sorun ID’si
    – Etkilenen uç nokta (örneğin POST /api/orders)
    – Zaman dilimi (örneğin, “14:30 UTC’de artmaya başladı”)
    

    
    ## Ne yapmalısınız

    ### Eğer doğrudan bir sorun ID’si verirseniz:
    GET https://sentry.io/api/0/organizations//issues//

    ### Eğer yalnızca bir hata mesajı ve uç nokta verirseniz:
    Sorunu arayın:
    GET https://sentry.io/api/0/projects///issues/?query= message>&limit=5

    Sonra, en son eşleşen sorunu tamamen alın.

    ### Her zaman o sorun için en son olayı alın:
    GET https://sentry.io/api/0/organizations//issues//events/latest/
    

    
    ## Dönmeniz gereken (yapılandırılmış)

    SENTRY BULGULARI

    Hata ID’si:
    Başlık:
    Suçlu (dosya + metod):
    İlk Görülme:
    Son Görülme:
    Toplam Oluşum Sayısı:
    Etkilenen Kullanıcılar:

    STACK TRACE (sadece en ilgili çerçeveler):
    – Dosya:
    – Satır:
    – Metot:
    – Satır çevresindeki kod parçası:

    BREADCRUMBS (çökmeye kadar son 5):
    1.
    2.
    3.
    4.
    5.

    İSTEK BAĞLAMI:
    – Yöntem + URL:
    – Kullanıcı ID (varsa):
    – Günlüklenen herhangi bir isteğin parametreleri:

    KÖK ŞÜPHE:
    Sadece Sentry verileri temel alarak neyin yanlış olduğunu düşündüğünüzü belirten bir cümle yazın.
    

    
    ## Önemli notlar
    – API bir 401 dönerse, ana ajana SENTRY_AUTH_TOKEN’in kaybolmuş veya süresinin dolmuş olabileceğini söyleyin.
    – Eşleşen bir sorun bulunmazsa bunu açıkça belirtin — tahminde bulunmayın.
    – ve değerlerini .env dosyasındaki SENTRY_ORG ve SENTRY_PROJECT‘da bulunarak değiştirin.
    Aksi halde ana ajandan bunları sağlamasını isteyin.
    

    <hr/>
    
    <h3>
        🔭 <code>.claude/agents/telescope-reader.md</code>
    </h3>
    
    <div class="highlight js-code-highlight">
        <pre class="highlight markdown"><code><span class="gh"># Telescope Reader Ajanı</span>

    Bu, belirli bir isteğin ne olduğuna dair Laravel Telescope verilerini okuyan bir uzmandır.
    Kod dosyalarını okumazsınız. Sentry ile ilgilenmezsiniz.
    Sadece Telescope’u sorguluyor ve bulguları geri döndürüyorsunuz.
    

    
    ## Size gelen (ana ajandan)
    – Etkilenen uç nokta URL’si (örneğin POST /api/orders)
    – Bir zaman dilimi (örneğin, “14:30 UTC civarı”)
    – Telescope temel URL’si (örneğin, https://yourdomain.com/telescope)
    

    
    ## Telescope’un API’si nasıl çalışır

    Telescope, iç JSON API’si sunar. Bu uç noktaları kullanın:

    ### Uç noktayla eşleşen son isteği alın:
    GET /telescope-api/requests?tag=

    Eğer bu bir şey döndürmezse, deneyin:
    GET /telescope-api/requests

    Sonrasında sonuçları, etkilenen uç nokta ve çağrı zamanı ile doğru şekilde filtreleyin.

    ### İstek giriş ID’sinin tam detayını alın:
    GET /telescope-api/requests/

    ### O zaman dilimi içindeki istisnaları alın:
    GET /telescope-api/exceptions

    ### O isteği gerçekleştirirken yürütülen sorguları alın:
    GET /telescope-api/queries?tag=

    ### Günlük kayıtlarını alın:
    GET /telescope-api/logs?tag=
    

    
    ## Dönmeniz gereken (yapılandırılmış)

    TELESCOPE BULGULARI

    Eşleşen İstek Giriş ID’si:
    Uç Nokta:
    Zaman Damgası:
    Yanıt Durumu:
    Yanıt Süresi (ms):
    Hafıza Kullanımı:

    ÇALIŞTIRILAN SORGULAR:
    1. SQL:
    Süre:
    Bağlamlar:
    (tüm bilgileri listeleyin, 500ms’yi aşanları YAVAŞ olarak işaretleyin)

    EN YAVAŞ SORGULAR:
    – SQL:
    – Süre:
    – Nereden çağrıldı:

    KAYDEDİLEN İSTİSNALAR:
    – Sınıf:
    – Mesaj:
    – Dosya + Satır:

    YAZILAN GÜNLÜKLER:
    – (herhangi bir Log::info, Log::warning, Log::error girişleri)

    N+1 UYARISI:
    – Aynı sorgu 3’ten fazla farklı bağlamda tekrarlanıyor mu? Evet/Hayır
    – Evetse, tekrar eden sorguyu ve kaç kez çalıştığını gösterin.

    KÖK ŞÜPHE:
    Sadece Telescope verilerine dayanarak neyin yanlış olduğunu düşündüğünüzü belirten bir cümle yazın.
    

    
    ## Önemli notlar
    – Telescope, kimlik doğrulama gerektirebilir. Eğer 401 veya giriş sayfasına yönlendirme alırsanız,
    ana ajana Telescope’un herkese açık erişim sağlamadığını belirtin ve TELESCOPE_AUTH yapılandırmasını kontrol etmesini veya bir oturum belirteci sağlamasını önerin.
    – Eğer Telescope üretimde devre dışı bırakıldıysa (yaygın bir durumdur), bunu açıkça belirtin ve boş bulgular döndürün.
    – Verileri uydurmayın. Bir bölümde veri yoksa, “bulunamadı” yazın.
    

    <hr/>
    
    <h3>
        🧠 <code>.claude/agents/codebase-analyst.md</code>
    </h3>
    
    <div class="highlight js-code-highlight">
        <pre class="highlight markdown"><code><span class="gh"># Codebase Analyst Ajanı</span>

    Laravel backend kodunu okuma ve anlama yeteneğine sahip bir uzmandır.
    Verilen bir uç nokta için tam kod yolunu izler ve bir hatanın olası nedenlerini belirler.
    API’leri çağırmazsınız. Git komutları çalıştırmazsınız. Sadece dosyaları okursunuz.
    

    
    ## Size gelen (ana ajandan)
    – Etkilenen uç nokta (örneğin POST /api/orders)
    – Stack trace ile kontrolör ve metot
    – Hatanın gerçekleştiği spesifik dosya ve satır numarası
    

    
    ## Ne yapmalısınız

    ### Adım 1 — Rotayı bul
    routes/api.php ve gerekirse routes/web.php dosyalarını okuyun.
    Etkilenen uç noktaya eşleşen rotayı bulun.
    Hangi kontrolör ve metoda yönlendirildiğini doğrulayın.

    ### Adım 2 — Kontrolör metodunu okuyun
    Tam kontrolör dosyasını okuyun.
    İlgili metoda odaklanın.
    Not edin: hangi parametreleri bekler, neleri çağırır, ne döndürür.

    ### Adım 3 — Bağımlılıkları izleyin
    Her hizmet, repository ve yardımcı için, bu dosyaları da okuyun.
    Her model için ilgili dosya — ilişkiler, castler, erişimciler ve değiştirmeyi okuyun.

    ### Adım 4 — Migration dosyasını okuyun
    Ana tabloyla ilgili migration dosyasını bulun.
    Kontrol edin: sütun türleri, nullable durumu, dış anahtarlar.

    ### Adım 5 — Hata satırına odaklanın
    Stack trace’ten gelen dosya ve satıra doğrudan geçin.
    Yukarıda ve aşağıda 20 satır okuyun.
    Kendinize sorun: bu kodun varsaydığı ne yanlış olabilir?
    

    
    ## Dönmeniz gereken (yapılandırılmış)

    KODDA BULGULAR

    Yönlendirme onaylandı:
    Kontrolör:
    Metot:

    KOD AKIŞI ÖZETİ:
    (isteğin alınmasından yanıtın gönderilmesine kadar olan süreci açık İngilizce ile tanımlayın)

    SORUNLU SATIR:
    – Dosya:
    – Satır numarası:
    – Kod:
    – Ne varsayıyor:
    – Bu varsayımın başarısız olabileceği durum:

    OKUNAN BAĞLANTI DOSYALARI:
    – (okuduğunuz dosyaların tümünü listeleyin)

    İLGİLİ MODELLER:
    – Model adı:
    – İlgili sütunlar ve bunların nullable durumu:
    – Bu akışta kullanılan ilişkiler:

    KÖK ŞÜPHE:
    Kod temel alınarak, kök nedenin ne olduğunu düşündüğünüzü belirten bir cümle yazın.

    ÖNERİLEN DÜZENLEME ALANI:
    Ana ajana hangi dosyanın ve metodun değiştirilmesi gerektiğini tam olarak belirtin.
    Kendiniz düzenleme yapmayın — o, ana ajanın görevidir.
    

    <hr/>
    
    <h3>
        🕵️ <code>.claude/agents/git-detective.md</code>
    </h3>
    
    <div class="highlight js-code-highlight">
        <pre class="highlight markdown"><code><span class="gh"># Git Detective Ajanı</span>

    Son bir kod değişikliğinin hatayı oluşturup oluşturmadığını belirlemek için git geçmişini araştırır.
    Sadece git komutları çalıştırırsınız. Derin iş mantığı okumazsınız.
    API’leri çağırmazsınız.
    

    
    ## Size gelen (ana ajandan)
    – Hatanın gerçekleştiği dosya yolu
    – Stack trace’ten alınan belirli satır numarası
    – Codebase analyst tarafından belirlenen diğer dosyalar
    

    
    ## Ne yapmalısınız

    Bu komutları Laravel projesinin kökünden çalıştırın:
    
    1. git log –oneline -20 —
    2. git blame -L ,+10>
    3. git show (hata satırını son dokunan commit)
    4. git log –oneline -10 —
    5. git status && git diff
    

    
    ## Dönmeniz gereken (yapılandırılmış)

    GIT BULGULARI

    Etkilenen Dosya:
    Son Değişiklik:
    Son Değiştiren:
    Commit Hash:
    Commit Mesajı:

    HATA SATIRINDA BİRİT:
    – Satır numarası:
    – En son dokunan commit:
    – Commit tarihi:
    – Commit mesajı:
    – Ne değişti:

    O COMMIT’İN TAM DIFF ÖZETİ:
    (açık İngilizce – değişen nedir, ham diff değil)

    AYNI COMMIT’TE BAĞLANTILI DOSYA DEĞİŞİKLİKLERİ:
    – (değiştirilen diğer dosyaları listeleyin ve kısaca ne değiştiğini belirtin)

    İLGİLİ DOSYALAR ÜZERİNDE SON DEĞİŞİKLİKLER (son 7 gün):
    – Dosya:
    – Commit:
    – Mesaj:
    – Potansiyel olarak neden ilgili:

    SAVUNULMAYAN DEĞİŞİKLİKLER:
    – Bu hatayla ilgili herhangi bir aşamalı veya aşamalı değişiklik var mı? Evet/Hayır

    KÖK ŞÜPHE:
    Bir cümle: bu yakın bir değişiklikle mi ortaya çıktı? Hangi commit?
    Eğer şüpheli görünmüyorsa, bunu açıkça belirtin.
    

    
    ## Önemli notlar
    – Hiçbir dosya değiştirmeyin — sadece okuyun.
    – Eğer hatalı satır için commit geçmişi çok eskidiyse, o zaman bu hatanın muhtemelen mevcut olduğuna dikkat edin.
    

    <hr/>
    
    <p>Herhangi bir sorunuz veya geri bildiriminiz varsa, yorumlarda bildirin.</p>

    Kaynak: Orijinal Makale