mirror of
https://github.com/affaan-m/everything-claude-code.git
synced 2026-04-08 02:03:34 +08:00
Add Turkish (tr) docs and update README (#744)
* Add Turkish (tr) docs and update README Add a full set of Turkish documentation under docs/tr (agents, changelog, CLAUDE guide, contributing, code of conduct, and many agents/commands/skills/rules files). Update README to include a link to the Turkish docs and increment the supported language count from 5 to 6. This commit adds localized guidance and references to help Turkish-speaking contributors and users. * Update docs/tr/TROUBLESHOOTING.md Co-authored-by: cubic-dev-ai[bot] <191113872+cubic-dev-ai[bot]@users.noreply.github.com> * Update docs/tr/README.md Co-authored-by: cubic-dev-ai[bot] <191113872+cubic-dev-ai[bot]@users.noreply.github.com> * docs(tr): fix license link and update readmes Update Turkish docs: change license badge link to point to repository root (../../LICENSE), increment displayed language count from 5 to 6, and remove two outdated related links from docs/tr/examples/README.md to keep references accurate. * Update docs/tr/commands/instinct-import.md Co-authored-by: cubic-dev-ai[bot] <191113872+cubic-dev-ai[bot]@users.noreply.github.com> * Update docs/tr/commands/checkpoint.md Co-authored-by: cubic-dev-ai[bot] <191113872+cubic-dev-ai[bot]@users.noreply.github.com> --------- Co-authored-by: cubic-dev-ai[bot] <191113872+cubic-dev-ai[bot]@users.noreply.github.com>
This commit is contained in:
committed by
GitHub
parent
bb1efad7c7
commit
fd2a8edb53
62
docs/tr/commands/build-fix.md
Normal file
62
docs/tr/commands/build-fix.md
Normal file
@@ -0,0 +1,62 @@
|
||||
# Build and Fix
|
||||
|
||||
Build ve tip hatalarını minimal, güvenli değişikliklerle aşamalı olarak düzelt.
|
||||
|
||||
## Adım 1: Build Sistemini Tespit Et
|
||||
|
||||
Projenin build aracını tanımla ve build'i çalıştır:
|
||||
|
||||
| İndikatör | Build Komutu |
|
||||
|-----------|---------------|
|
||||
| `build` script'i olan `package.json` | `npm run build` veya `pnpm build` |
|
||||
| `tsconfig.json` (sadece TypeScript) | `npx tsc --noEmit` |
|
||||
| `Cargo.toml` | `cargo build 2>&1` |
|
||||
| `pom.xml` | `mvn compile` |
|
||||
| `build.gradle` | `./gradlew compileJava` |
|
||||
| `go.mod` | `go build ./...` |
|
||||
| `pyproject.toml` | `python -m py_compile` veya `mypy .` |
|
||||
|
||||
## Adım 2: Hataları Parse Et ve Grupla
|
||||
|
||||
1. Build komutunu çalıştır ve stderr'i yakala
|
||||
2. Hataları dosya yoluna göre grupla
|
||||
3. Bağımlılık sırasına göre sırala (mantık hatalarından önce import/tipleri düzelt)
|
||||
4. İlerleme takibi için toplam hataları say
|
||||
|
||||
## Adım 3: Düzeltme Döngüsü (Tek Seferde Bir Hata)
|
||||
|
||||
Her hata için:
|
||||
|
||||
1. **Dosyayı oku** — Hata bağlamını görmek için Read aracını kullan (hatanın etrafında 10 satır)
|
||||
2. **Teşhis et** — Kök nedeni tanımla (eksik import, yanlış tip, sözdizimi hatası)
|
||||
3. **Minimal düzelt** — Hatayı çözen en küçük değişiklik için Edit aracını kullan
|
||||
4. **Build'i yeniden çalıştır** — Hatanın gittiğini ve yeni hata oluşmadığını doğrula
|
||||
5. **Sonrakine geç** — Kalan hatalarla devam et
|
||||
|
||||
## Adım 4: Koruma Önlemleri
|
||||
|
||||
Şu durumlarda dur ve kullanıcıya sor:
|
||||
- Bir düzeltme **çözdüğünden daha fazla hata oluşturuyorsa**
|
||||
- **Aynı hata 3 denemeden sonra devam ediyorsa** (muhtemelen daha derin bir sorun)
|
||||
- Düzeltme **mimari değişiklikler gerektiriyorsa** (sadece build düzeltmesi değil)
|
||||
- Build hataları **eksik bağımlılıklardan** kaynaklanıyorsa (`npm install`, `cargo add`, vb. gerekli)
|
||||
|
||||
## Adım 5: Özet
|
||||
|
||||
Sonuçları göster:
|
||||
- Düzeltilen hatalar (dosya yollarıyla)
|
||||
- Kalan hatalar (varsa)
|
||||
- Oluşturulan yeni hatalar (sıfır olmalı)
|
||||
- Çözülmemiş sorunlar için önerilen sonraki adımlar
|
||||
|
||||
## Kurtarma Stratejileri
|
||||
|
||||
| Durum | Aksiyon |
|
||||
|-----------|--------|
|
||||
| Eksik modül/import | Paketin yüklü olup olmadığını kontrol et; install komutu öner |
|
||||
| Tip uyuşmazlığı | Her iki tip tanımını oku; daha dar olanı düzelt |
|
||||
| Döngüsel bağımlılık | Import grafiği ile döngüyü tanımla; extraction öner |
|
||||
| Versiyon çakışması | Versiyon kısıtlamaları için `package.json` / `Cargo.toml` kontrol et |
|
||||
| Build aracı yanlış yapılandırması | Config dosyasını oku; çalışan varsayılanlarla karşılaştır |
|
||||
|
||||
Güvenlik için bir seferde bir hatayı düzelt. Refactoring yerine minimal diff'leri tercih et.
|
||||
74
docs/tr/commands/checkpoint.md
Normal file
74
docs/tr/commands/checkpoint.md
Normal file
@@ -0,0 +1,74 @@
|
||||
# Checkpoint Komutu
|
||||
|
||||
İş akışınızda bir checkpoint oluşturun veya doğrulayın.
|
||||
|
||||
## Kullanım
|
||||
|
||||
`/checkpoint [create|verify|list|clear] [isim]`
|
||||
|
||||
## Checkpoint Oluştur
|
||||
|
||||
Checkpoint oluştururken:
|
||||
|
||||
1. Mevcut durumun temiz olduğundan emin olmak için `/verify quick` çalıştır
|
||||
2. Checkpoint adıyla bir git stash veya commit oluştur
|
||||
3. Checkpoint'i `.claude/checkpoints.log`'a kaydet:
|
||||
|
||||
```bash
|
||||
echo "$(date +%Y-%m-%d-%H:%M) | $CHECKPOINT_NAME | $(git rev-parse --short HEAD)" >> .claude/checkpoints.log
|
||||
```
|
||||
|
||||
4. Checkpoint oluşturulduğunu raporla
|
||||
|
||||
## Checkpoint'i Doğrula
|
||||
|
||||
Bir checkpoint'e karşı doğrularken:
|
||||
|
||||
1. Log'dan checkpoint'i oku
|
||||
2. Mevcut durumu checkpoint ile karşılaştır:
|
||||
- Checkpoint'ten sonra eklenen dosyalar
|
||||
- Checkpoint'ten sonra değiştirilen dosyalar
|
||||
- Şimdiki vs o zamanki test başarı oranı
|
||||
- Şimdiki vs o zamanki kapsama oranı
|
||||
|
||||
3. Raporla:
|
||||
```
|
||||
CHECKPOINT KARŞILAŞTIRMASI: $NAME
|
||||
============================
|
||||
Değişen dosyalar: X
|
||||
Testler: +Y geçti / -Z başarısız
|
||||
Kapsama: +X% / -Y%
|
||||
Build: [GEÇTİ/BAŞARISIZ]
|
||||
```
|
||||
|
||||
## Checkpoint'leri Listele
|
||||
|
||||
Tüm checkpoint'leri şunlarla göster:
|
||||
- Ad
|
||||
- Zaman damgası
|
||||
- Git SHA
|
||||
- Durum (mevcut, geride, ileride)
|
||||
|
||||
## İş Akışı
|
||||
|
||||
Tipik checkpoint akışı:
|
||||
|
||||
```
|
||||
[Başlangıç] --> /checkpoint create "feature-start"
|
||||
|
|
||||
[Uygula] --> /checkpoint create "core-done"
|
||||
|
|
||||
[Test] --> /checkpoint verify "core-done"
|
||||
|
|
||||
[Refactor] --> /checkpoint create "refactor-done"
|
||||
|
|
||||
[PR] --> /checkpoint verify "feature-start"
|
||||
```
|
||||
|
||||
## Argümanlar
|
||||
|
||||
$ARGUMENTS:
|
||||
- `create <isim>` - İsimlendirilmiş checkpoint oluştur
|
||||
- `verify <isim>` - İsimlendirilmiş checkpoint'e karşı doğrula
|
||||
- `list` - Tüm checkpoint'leri göster
|
||||
- `clear` - Eski checkpoint'leri kaldır (son 5'i tutar)
|
||||
40
docs/tr/commands/code-review.md
Normal file
40
docs/tr/commands/code-review.md
Normal file
@@ -0,0 +1,40 @@
|
||||
# Code Review
|
||||
|
||||
Commit edilmemiş değişikliklerin kapsamlı güvenlik ve kalite incelemesi:
|
||||
|
||||
1. Değişen dosyaları al: git diff --name-only HEAD
|
||||
|
||||
2. Her değişen dosya için şunları kontrol et:
|
||||
|
||||
**Güvenlik Sorunları (KRİTİK):**
|
||||
- Hardcode edilmiş kimlik bilgileri, API anahtarları, token'lar
|
||||
- SQL injection açıklıkları
|
||||
- XSS açıklıkları
|
||||
- Eksik input validasyonu
|
||||
- Güvenli olmayan bağımlılıklar
|
||||
- Path traversal riskleri
|
||||
|
||||
**Kod Kalitesi (YÜKSEK):**
|
||||
- 50 satırdan uzun fonksiyonlar
|
||||
- 800 satırdan uzun dosyalar
|
||||
- 4 seviyeden fazla iç içe geçme derinliği
|
||||
- Eksik hata yönetimi
|
||||
- console.log ifadeleri
|
||||
- TODO/FIXME yorumları
|
||||
- Public API'ler için eksik JSDoc
|
||||
|
||||
**En İyi Uygulamalar (ORTA):**
|
||||
- Mutation desenleri (immutable kullanın)
|
||||
- Kod/yorumlarda emoji kullanımı
|
||||
- Yeni kod için eksik testler
|
||||
- Erişilebilirlik sorunları (a11y)
|
||||
|
||||
3. Şunları içeren rapor oluştur:
|
||||
- Önem derecesi: KRİTİK, YÜKSEK, ORTA, DÜŞÜK
|
||||
- Dosya konumu ve satır numaraları
|
||||
- Sorun açıklaması
|
||||
- Önerilen düzeltme
|
||||
|
||||
4. KRİTİK veya YÜKSEK sorunlar bulunursa commit'i engelle
|
||||
|
||||
Güvenlik açıklıkları olan kodu asla onaylamayın!
|
||||
365
docs/tr/commands/e2e.md
Normal file
365
docs/tr/commands/e2e.md
Normal file
@@ -0,0 +1,365 @@
|
||||
---
|
||||
description: Playwright ile end-to-end testler oluştur ve çalıştır. Test yolculukları oluşturur, testleri çalıştırır, ekran görüntüleri/videolar/izlemeler yakalar ve artifact'ları yükler.
|
||||
---
|
||||
|
||||
# E2E Komutu
|
||||
|
||||
Bu komut, Playwright kullanarak end-to-end testleri oluşturmak, sürdürmek ve yürütmek için **e2e-runner** agent'ını çağırır.
|
||||
|
||||
## Bu Komut Ne Yapar
|
||||
|
||||
1. **Test Yolculukları Oluştur** - Kullanıcı akışları için Playwright testleri oluştur
|
||||
2. **E2E Testlerini Çalıştır** - Testleri tarayıcılar arasında yürüt
|
||||
3. **Artifact'ları Yakala** - Hatalarda ekran görüntüleri, videolar, izlemeler
|
||||
4. **Sonuçları Yükle** - HTML raporları ve JUnit XML
|
||||
5. **Dengesiz Testleri Tanımla** - Kararsız testleri karantinaya al
|
||||
|
||||
## Ne Zaman Kullanılır
|
||||
|
||||
`/e2e` komutunu şu durumlarda kullanın:
|
||||
- Kritik kullanıcı yolculuklarını test ederken (giriş, ticaret, ödemeler)
|
||||
- Çok adımlı akışların uçtan uca çalıştığını doğrularken
|
||||
- UI etkileşimlerini ve navigasyonu test ederken
|
||||
- Frontend ve backend arasındaki entegrasyonu doğrularken
|
||||
- Üretime dağıtım için hazırlanırken
|
||||
|
||||
## Nasıl Çalışır
|
||||
|
||||
e2e-runner agent'ı şunları yapacaktır:
|
||||
|
||||
1. **Kullanıcı akışını analiz edecek** ve test senaryolarını tanımlayacak
|
||||
2. Page Object Model deseni kullanarak **Playwright testi oluşturacak**
|
||||
3. **Testleri çalıştıracak** (Chrome, Firefox, Safari)
|
||||
4. Ekran görüntüleri, videolar ve izlemelerle **hataları yakalayacak**
|
||||
5. Sonuçlar ve artifact'larla **rapor oluşturacak**
|
||||
6. **Dengesiz testleri tanımlayacak** ve düzeltme önerilerinde bulunacak
|
||||
|
||||
## Örnek Kullanım
|
||||
|
||||
```
|
||||
Kullanıcı: /e2e Piyasa arama ve görüntüleme akışını test et
|
||||
|
||||
Agent (e2e-runner):
|
||||
# E2E Test Oluşturma: Piyasa Arama ve Görüntüleme Akışı
|
||||
|
||||
## Tanımlanan Test Senaryosu
|
||||
|
||||
**Kullanıcı Yolculuğu:** Piyasa Arama → Sonuçları Görüntüle → Piyasaya Tıkla → Detayları Görüntüle
|
||||
|
||||
**Test Kapsamı:**
|
||||
1. Piyasalar sayfasına git
|
||||
2. Semantik arama yap
|
||||
3. Arama sonuçlarını doğrula
|
||||
4. İlk sonuca tıkla
|
||||
5. Piyasa detay sayfasının yüklendiğini doğrula
|
||||
6. Grafiğin render olduğunu doğrula
|
||||
|
||||
## Oluşturulan Test Kodu
|
||||
|
||||
```typescript
|
||||
// tests/e2e/markets/search-and-view.spec.ts
|
||||
import { test, expect } from '@playwright/test'
|
||||
import { MarketsPage } from '../../pages/MarketsPage'
|
||||
import { MarketDetailsPage } from '../../pages/MarketDetailsPage'
|
||||
|
||||
test.describe('Market Search and View Flow', () => {
|
||||
test('kullanıcı piyasaları arayabilir ve detayları görüntüleyebilir', async ({ page }) => {
|
||||
// 1. Piyasalar sayfasına git
|
||||
const marketsPage = new MarketsPage(page)
|
||||
await marketsPage.goto()
|
||||
|
||||
// Sayfanın yüklendiğini doğrula
|
||||
await expect(page).toHaveTitle(/Markets/)
|
||||
await expect(page.locator('h1')).toContainText('Markets')
|
||||
|
||||
// 2. Semantik arama yap
|
||||
await marketsPage.searchMarkets('election')
|
||||
|
||||
// API yanıtını bekle
|
||||
await page.waitForResponse(resp =>
|
||||
resp.url().includes('/api/markets/search') && resp.status() === 200
|
||||
)
|
||||
|
||||
// 3. Arama sonuçlarını doğrula
|
||||
const marketCards = marketsPage.marketCards
|
||||
await expect(marketCards.first()).toBeVisible()
|
||||
const resultCount = await marketCards.count()
|
||||
expect(resultCount).toBeGreaterThan(0)
|
||||
|
||||
// Arama sonuçlarının ekran görüntüsünü al
|
||||
await page.screenshot({ path: 'artifacts/search-results.png' })
|
||||
|
||||
// 4. İlk sonuca tıkla
|
||||
const firstMarketTitle = await marketCards.first().textContent()
|
||||
await marketCards.first().click()
|
||||
|
||||
// 5. Piyasa detay sayfasının yüklendiğini doğrula
|
||||
await expect(page).toHaveURL(/\/markets\/[a-z0-9-]+/)
|
||||
|
||||
const detailsPage = new MarketDetailsPage(page)
|
||||
await expect(detailsPage.marketName).toBeVisible()
|
||||
await expect(detailsPage.marketDescription).toBeVisible()
|
||||
|
||||
// 6. Grafiğin render olduğunu doğrula
|
||||
await expect(detailsPage.priceChart).toBeVisible()
|
||||
|
||||
// Piyasa adının eşleştiğini doğrula
|
||||
const detailsTitle = await detailsPage.marketName.textContent()
|
||||
expect(detailsTitle?.toLowerCase()).toContain(
|
||||
firstMarketTitle?.toLowerCase().substring(0, 20) || ''
|
||||
)
|
||||
|
||||
// Piyasa detaylarının ekran görüntüsünü al
|
||||
await page.screenshot({ path: 'artifacts/market-details.png' })
|
||||
})
|
||||
|
||||
test('sonuç olmayan arama boş durumu göstermeli', async ({ page }) => {
|
||||
const marketsPage = new MarketsPage(page)
|
||||
await marketsPage.goto()
|
||||
|
||||
// Var olmayan piyasayı ara
|
||||
await marketsPage.searchMarkets('xyznonexistentmarket123456')
|
||||
|
||||
// Boş durumu doğrula
|
||||
await expect(page.locator('[data-testid="no-results"]')).toBeVisible()
|
||||
await expect(page.locator('[data-testid="no-results"]')).toContainText(
|
||||
/no.*results|no.*markets/i
|
||||
)
|
||||
|
||||
const marketCount = await marketsPage.marketCards.count()
|
||||
expect(marketCount).toBe(0)
|
||||
})
|
||||
|
||||
test('aramayı temizleyebilir ve tüm piyasaları tekrar görebilir', async ({ page }) => {
|
||||
const marketsPage = new MarketsPage(page)
|
||||
await marketsPage.goto()
|
||||
|
||||
// İlk piyasa sayısı
|
||||
const initialCount = await marketsPage.marketCards.count()
|
||||
|
||||
// Arama yap
|
||||
await marketsPage.searchMarkets('trump')
|
||||
await page.waitForLoadState('networkidle')
|
||||
|
||||
// Filtrelenmiş sonuçları doğrula
|
||||
const filteredCount = await marketsPage.marketCards.count()
|
||||
expect(filteredCount).toBeLessThan(initialCount)
|
||||
|
||||
// Aramayı temizle
|
||||
await marketsPage.searchInput.clear()
|
||||
await page.waitForLoadState('networkidle')
|
||||
|
||||
// Tüm piyasaların tekrar gösterildiğini doğrula
|
||||
const finalCount = await marketsPage.marketCards.count()
|
||||
expect(finalCount).toBe(initialCount)
|
||||
})
|
||||
})
|
||||
```
|
||||
|
||||
## Testleri Çalıştırma
|
||||
|
||||
```bash
|
||||
# Oluşturulan testi çalıştır
|
||||
npx playwright test tests/e2e/markets/search-and-view.spec.ts
|
||||
|
||||
3 worker kullanarak 3 test çalıştırılıyor
|
||||
|
||||
✓ [chromium] › search-and-view.spec.ts:5:3 › user can search markets and view details (4.2s)
|
||||
✓ [chromium] › search-and-view.spec.ts:52:3 › search with no results shows empty state (1.8s)
|
||||
✓ [chromium] › search-and-view.spec.ts:67:3 › can clear search and see all markets again (2.9s)
|
||||
|
||||
3 passed (9.1s)
|
||||
|
||||
Oluşturulan artifact'lar:
|
||||
- artifacts/search-results.png
|
||||
- artifacts/market-details.png
|
||||
- playwright-report/index.html
|
||||
```
|
||||
|
||||
## Test Raporu
|
||||
|
||||
```
|
||||
╔══════════════════════════════════════════════════════════════╗
|
||||
║ E2E Test Sonuçları ║
|
||||
╠══════════════════════════════════════════════════════════════╣
|
||||
║ Durum: ✅ TÜM TESTLER GEÇTİ ║
|
||||
║ Toplam: 3 test ║
|
||||
║ Geçti: 3 (%100) ║
|
||||
║ Başarısız: 0 ║
|
||||
║ Dengesiz: 0 ║
|
||||
║ Süre: 9.1s ║
|
||||
╚══════════════════════════════════════════════════════════════╝
|
||||
|
||||
Artifact'lar:
|
||||
📸 Ekran Görüntüleri: 2 dosya
|
||||
📹 Videolar: 0 dosya (sadece hatada)
|
||||
🔍 İzlemeler: 0 dosya (sadece hatada)
|
||||
📊 HTML Rapor: playwright-report/index.html
|
||||
|
||||
Raporu görüntüle: npx playwright show-report
|
||||
```
|
||||
|
||||
✅ E2E test paketi CI/CD entegrasyonuna hazır!
|
||||
```
|
||||
|
||||
## Test Artifact'ları
|
||||
|
||||
Testler çalıştığında, şu artifact'lar yakalanır:
|
||||
|
||||
**Tüm Testlerde:**
|
||||
- Zaman çizelgesi ve sonuçlarla HTML Rapor
|
||||
- CI entegrasyonu için JUnit XML
|
||||
|
||||
**Sadece Hatada:**
|
||||
- Başarısız durumun ekran görüntüsü
|
||||
- Testin video kaydı
|
||||
- Hata ayıklama için izleme dosyası (adım adım tekrar)
|
||||
- Network logları
|
||||
- Console logları
|
||||
|
||||
## Artifact'ları Görüntüleme
|
||||
|
||||
```bash
|
||||
# HTML raporunu tarayıcıda görüntüle
|
||||
npx playwright show-report
|
||||
|
||||
# Belirli izleme dosyasını görüntüle
|
||||
npx playwright show-trace artifacts/trace-abc123.zip
|
||||
|
||||
# Ekran görüntüleri artifacts/ dizinine kaydedilir
|
||||
open artifacts/search-results.png
|
||||
```
|
||||
|
||||
## Dengesiz Test Tespiti
|
||||
|
||||
Bir test aralıklı olarak başarısız olursa:
|
||||
|
||||
```
|
||||
⚠️ DENGESİZ TEST TESPİT EDİLDİ: tests/e2e/markets/trade.spec.ts
|
||||
|
||||
Test 10 çalıştırmadan 7'sinde geçti (%70 geçme oranı)
|
||||
|
||||
Yaygın başarısızlık:
|
||||
"'[data-testid="confirm-btn"]' elementi için timeout"
|
||||
|
||||
Önerilen düzeltmeler:
|
||||
1. Açık bekleme ekle: await page.waitForSelector('[data-testid="confirm-btn"]')
|
||||
2. Timeout'u artır: { timeout: 10000 }
|
||||
3. Component'te yarış koşullarını kontrol et
|
||||
4. Elementin animasyon tarafından gizlenmediğini doğrula
|
||||
|
||||
Karantina önerisi: Düzeltilene kadar test.fixme() olarak işaretle
|
||||
```
|
||||
|
||||
## Tarayıcı Yapılandırması
|
||||
|
||||
Testler varsayılan olarak birden fazla tarayıcıda çalışır:
|
||||
- ✅ Chromium (Desktop Chrome)
|
||||
- ✅ Firefox (Desktop)
|
||||
- ✅ WebKit (Desktop Safari)
|
||||
- ✅ Mobile Chrome (opsiyonel)
|
||||
|
||||
Tarayıcıları ayarlamak için `playwright.config.ts`'yi yapılandırın.
|
||||
|
||||
## CI/CD Entegrasyonu
|
||||
|
||||
CI pipeline'ınıza ekleyin:
|
||||
|
||||
```yaml
|
||||
# .github/workflows/e2e.yml
|
||||
- name: Install Playwright
|
||||
run: npx playwright install --with-deps
|
||||
|
||||
- name: Run E2E tests
|
||||
run: npx playwright test
|
||||
|
||||
- name: Upload artifacts
|
||||
if: always()
|
||||
uses: actions/upload-artifact@v3
|
||||
with:
|
||||
name: playwright-report
|
||||
path: playwright-report/
|
||||
```
|
||||
|
||||
## PMX'e Özgü Kritik Akışlar
|
||||
|
||||
PMX için bu E2E testlerine öncelik verin:
|
||||
|
||||
**🔴 KRİTİK (Her Zaman Geçmeli):**
|
||||
1. Kullanıcı cüzdan bağlayabilir
|
||||
2. Kullanıcı piyasalara göz atabilir
|
||||
3. Kullanıcı piyasa arayabilir (semantik arama)
|
||||
4. Kullanıcı piyasa detaylarını görüntüleyebilir
|
||||
5. Kullanıcı işlem yapabilir (test fonlarıyla)
|
||||
6. Piyasa doğru çözülür
|
||||
7. Kullanıcı fon çekebilir
|
||||
|
||||
**🟡 ÖNEMLİ:**
|
||||
1. Piyasa oluşturma akışı
|
||||
2. Kullanıcı profil güncellemeleri
|
||||
3. Gerçek zamanlı fiyat güncellemeleri
|
||||
4. Grafik render'ı
|
||||
5. Piyasaları filtreleme ve sıralama
|
||||
6. Mobil responsive layout
|
||||
|
||||
## En İyi Uygulamalar
|
||||
|
||||
**YAPIN:**
|
||||
- ✅ Sürdürülebilirlik için Page Object Model kullanın
|
||||
- ✅ Selector'lar için data-testid nitelikleri kullanın
|
||||
- ✅ Rastgele timeout'lar değil, API yanıtlarını bekleyin
|
||||
- ✅ Kritik kullanıcı yolculuklarını uçtan uca test edin
|
||||
- ✅ Main'e merge etmeden önce testleri çalıştırın
|
||||
- ✅ Testler başarısız olduğunda artifact'ları inceleyin
|
||||
|
||||
**YAPMAYIN:**
|
||||
- ❌ Kırılgan selector'lar kullanmayın (CSS sınıfları değişebilir)
|
||||
- ❌ Uygulama detaylarını test etmeyin
|
||||
- ❌ Production'a karşı testler çalıştırmayın
|
||||
- ❌ Dengesiz testleri görmezden gelmeyin
|
||||
- ❌ Başarısızlıklarda artifact incelemesini atlamayın
|
||||
- ❌ Her edge case'i E2E ile test etmeyin (unit testler kullanın)
|
||||
|
||||
## Önemli Notlar
|
||||
|
||||
**PMX için KRİTİK:**
|
||||
- Gerçek para içeren E2E testleri SADECE testnet/staging'de çalışmalıdır
|
||||
- Asla production'a karşı ticaret testleri çalıştırmayın
|
||||
- Finansal testler için `test.skip(process.env.NODE_ENV === 'production')` ayarlayın
|
||||
- Sadece küçük test fonlarıyla test cüzdanları kullanın
|
||||
|
||||
## Diğer Komutlarla Entegrasyon
|
||||
|
||||
- Test edilecek kritik yolculukları tanımlamak için `/plan` kullanın
|
||||
- Unit testler için `/tdd` kullanın (daha hızlı, daha ayrıntılı)
|
||||
- Entegrasyon ve kullanıcı yolculuk testleri için `/e2e` kullanın
|
||||
- Test kalitesini doğrulamak için `/code-review` kullanın
|
||||
|
||||
## İlgili Agent'lar
|
||||
|
||||
Bu komut, ECC tarafından sağlanan `e2e-runner` agent'ını çağırır.
|
||||
|
||||
Manuel kurulumlar için, kaynak dosya şurada bulunur:
|
||||
`agents/e2e-runner.md`
|
||||
|
||||
## Hızlı Komutlar
|
||||
|
||||
```bash
|
||||
# Tüm E2E testlerini çalıştır
|
||||
npx playwright test
|
||||
|
||||
# Belirli test dosyasını çalıştır
|
||||
npx playwright test tests/e2e/markets/search.spec.ts
|
||||
|
||||
# Headed modda çalıştır (tarayıcıyı gör)
|
||||
npx playwright test --headed
|
||||
|
||||
# Testi debug et
|
||||
npx playwright test --debug
|
||||
|
||||
# Test kodu oluştur
|
||||
npx playwright codegen http://localhost:3000
|
||||
|
||||
# Raporu görüntüle
|
||||
npx playwright show-report
|
||||
```
|
||||
120
docs/tr/commands/eval.md
Normal file
120
docs/tr/commands/eval.md
Normal file
@@ -0,0 +1,120 @@
|
||||
# Eval Komutu
|
||||
|
||||
Eval-odaklı geliştirme iş akışını yönet.
|
||||
|
||||
## Kullanım
|
||||
|
||||
`/eval [define|check|report|list] [feature-name]`
|
||||
|
||||
## Eval Tanımla
|
||||
|
||||
`/eval define feature-name`
|
||||
|
||||
Yeni bir eval tanımı oluştur:
|
||||
|
||||
1. Şablonla `.claude/evals/feature-name.md` oluştur:
|
||||
|
||||
```markdown
|
||||
## EVAL: feature-name
|
||||
Created: $(date)
|
||||
|
||||
### Capability Evals
|
||||
- [ ] [Capability 1 açıklaması]
|
||||
- [ ] [Capability 2 açıklaması]
|
||||
|
||||
### Regression Evals
|
||||
- [ ] [Mevcut davranış 1 hala çalışıyor]
|
||||
- [ ] [Mevcut davranış 2 hala çalışıyor]
|
||||
|
||||
### Success Criteria
|
||||
- pass@3 > 90% for capability evals
|
||||
- pass^3 = 100% for regression evals
|
||||
```
|
||||
|
||||
2. Kullanıcıdan belirli kriterleri doldurmasını iste
|
||||
|
||||
## Eval Kontrol Et
|
||||
|
||||
`/eval check feature-name`
|
||||
|
||||
Bir özellik için eval'ları çalıştır:
|
||||
|
||||
1. `.claude/evals/feature-name.md` dosyasından eval tanımını oku
|
||||
2. Her capability eval için:
|
||||
- Kriteri doğrulamayı dene
|
||||
- PASS/FAIL kaydet
|
||||
- Denemeyi `.claude/evals/feature-name.log` dosyasına kaydet
|
||||
3. Her regression eval için:
|
||||
- İlgili test'leri çalıştır
|
||||
- Baseline ile karşılaştır
|
||||
- PASS/FAIL kaydet
|
||||
4. Mevcut durumu raporla:
|
||||
|
||||
```
|
||||
EVAL CHECK: feature-name
|
||||
========================
|
||||
Capability: X/Y passing
|
||||
Regression: X/Y passing
|
||||
Status: IN PROGRESS / READY
|
||||
```
|
||||
|
||||
## Eval Raporu
|
||||
|
||||
`/eval report feature-name`
|
||||
|
||||
Kapsamlı eval raporu oluştur:
|
||||
|
||||
```
|
||||
EVAL REPORT: feature-name
|
||||
=========================
|
||||
Generated: $(date)
|
||||
|
||||
CAPABILITY EVALS
|
||||
----------------
|
||||
[eval-1]: PASS (pass@1)
|
||||
[eval-2]: PASS (pass@2) - required retry
|
||||
[eval-3]: FAIL - see notes
|
||||
|
||||
REGRESSION EVALS
|
||||
----------------
|
||||
[test-1]: PASS
|
||||
[test-2]: PASS
|
||||
[test-3]: PASS
|
||||
|
||||
METRICS
|
||||
-------
|
||||
Capability pass@1: 67%
|
||||
Capability pass@3: 100%
|
||||
Regression pass^3: 100%
|
||||
|
||||
NOTES
|
||||
-----
|
||||
[Herhangi bir sorun, edge case veya gözlem]
|
||||
|
||||
RECOMMENDATION
|
||||
--------------
|
||||
[SHIP / NEEDS WORK / BLOCKED]
|
||||
```
|
||||
|
||||
## Eval'ları Listele
|
||||
|
||||
`/eval list`
|
||||
|
||||
Tüm eval tanımlarını göster:
|
||||
|
||||
```
|
||||
EVAL DEFINITIONS
|
||||
================
|
||||
feature-auth [3/5 passing] IN PROGRESS
|
||||
feature-search [5/5 passing] READY
|
||||
feature-export [0/4 passing] NOT STARTED
|
||||
```
|
||||
|
||||
## Argümanlar
|
||||
|
||||
$ARGUMENTS:
|
||||
- `define <name>` - Yeni eval tanımı oluştur
|
||||
- `check <name>` - Eval'ları çalıştır ve kontrol et
|
||||
- `report <name>` - Tam rapor oluştur
|
||||
- `list` - Tüm eval'ları göster
|
||||
- `clean` - Eski eval loglarını kaldır (son 10 çalıştırmayı tutar)
|
||||
178
docs/tr/commands/evolve.md
Normal file
178
docs/tr/commands/evolve.md
Normal file
@@ -0,0 +1,178 @@
|
||||
---
|
||||
name: evolve
|
||||
description: İçgüdüleri analiz et ve evrimleşmiş yapılar öner veya oluştur
|
||||
command: true
|
||||
---
|
||||
|
||||
# Evolve Komutu
|
||||
|
||||
## Uygulama
|
||||
|
||||
Plugin root path kullanarak instinct CLI'ı çalıştır:
|
||||
|
||||
```bash
|
||||
python3 "${CLAUDE_PLUGIN_ROOT}/skills/continuous-learning-v2/scripts/instinct-cli.py" evolve [--generate]
|
||||
```
|
||||
|
||||
Veya `CLAUDE_PLUGIN_ROOT` ayarlanmamışsa (manuel kurulum):
|
||||
|
||||
```bash
|
||||
python3 ~/.claude/skills/continuous-learning-v2/scripts/instinct-cli.py evolve [--generate]
|
||||
```
|
||||
|
||||
İçgüdüleri analiz eder ve ilgili olanları daha üst seviye yapılara kümelendirir:
|
||||
- **Commands**: İçgüdüler kullanıcı tarafından çağrılan aksiyonları tanımladığında
|
||||
- **Skills**: İçgüdüler otomatik tetiklenen davranışları tanımladığında
|
||||
- **Agents**: İçgüdüler karmaşık, çok adımlı süreçleri tanımladığında
|
||||
|
||||
## Kullanım
|
||||
|
||||
```
|
||||
/evolve # Tüm içgüdüleri analiz et ve evrimleri öner
|
||||
/evolve --generate # Ayrıca evolved/{skills,commands,agents} altında dosyalar oluştur
|
||||
```
|
||||
|
||||
## Evrim Kuralları
|
||||
|
||||
### → Command (Kullanıcı Tarafından Çağrılan)
|
||||
İçgüdüler kullanıcının açıkça talep edeceği aksiyonları tanımladığında:
|
||||
- "Kullanıcı ... istediğinde" hakkında birden fazla içgüdü
|
||||
- "Yeni X oluştururken" gibi tetikleyicilere sahip içgüdüler
|
||||
- Tekrarlanabilir bir sıra izleyen içgüdüler
|
||||
|
||||
Örnek:
|
||||
- `new-table-step1`: "veritabanı tablosu eklerken, migration oluştur"
|
||||
- `new-table-step2`: "veritabanı tablosu eklerken, şemayı güncelle"
|
||||
- `new-table-step3`: "veritabanı tablosu eklerken, tipleri yeniden oluştur"
|
||||
|
||||
→ Oluşturur: **new-table** komutu
|
||||
|
||||
### → Skill (Otomatik Tetiklenen)
|
||||
İçgüdüler otomatik olarak gerçekleşmesi gereken davranışları tanımladığında:
|
||||
- Pattern-matching tetikleyiciler
|
||||
- Hata işleme yanıtları
|
||||
- Kod stili zorlaması
|
||||
|
||||
Örnek:
|
||||
- `prefer-functional`: "fonksiyon yazarken, functional stil tercih et"
|
||||
- `use-immutable`: "state değiştirirken, immutable pattern kullan"
|
||||
- `avoid-classes`: "modül tasarlarken, class-based tasarımdan kaçın"
|
||||
|
||||
→ Oluşturur: `functional-patterns` skill
|
||||
|
||||
### → Agent (Derinlik/İzolasyon Gerektirir)
|
||||
İçgüdüler izolasyondan fayda sağlayan karmaşık, çok adımlı süreçleri tanımladığında:
|
||||
- Debugging iş akışları
|
||||
- Refactoring dizileri
|
||||
- Araştırma görevleri
|
||||
|
||||
Örnek:
|
||||
- `debug-step1`: "debug yaparken, önce logları kontrol et"
|
||||
- `debug-step2`: "debug yaparken, başarısız componenti izole et"
|
||||
- `debug-step3`: "debug yaparken, minimal reproduction oluştur"
|
||||
- `debug-step4`: "debug yaparken, düzeltmeyi testle doğrula"
|
||||
|
||||
→ Oluşturur: **debugger** agent
|
||||
|
||||
## Yapılacaklar
|
||||
|
||||
1. Mevcut proje bağlamını tespit et
|
||||
2. Proje + global içgüdüleri oku (ID çakışmalarında proje önceliklidir)
|
||||
3. İçgüdüleri tetikleyici/domain desenlerine göre grupla
|
||||
4. Şunları tanımla:
|
||||
- Skill adayları (2+ içgüdüye sahip tetikleyici kümeleri)
|
||||
- Command adayları (yüksek güvenli workflow içgüdüleri)
|
||||
- Agent adayları (daha büyük, yüksek güvenli kümeler)
|
||||
5. Uygulanabilir durumlarda terfi adaylarını göster (proje -> global)
|
||||
6. `--generate` geçilirse, dosyaları şuraya yaz:
|
||||
- Proje kapsamı: `~/.claude/homunculus/projects/<project-id>/evolved/`
|
||||
- Global fallback: `~/.claude/homunculus/evolved/`
|
||||
|
||||
## Çıktı Formatı
|
||||
|
||||
```
|
||||
============================================================
|
||||
EVOLVE ANALYSIS - 12 instincts
|
||||
Project: my-app (a1b2c3d4e5f6)
|
||||
Project-scoped: 8 | Global: 4
|
||||
============================================================
|
||||
|
||||
High confidence instincts (>=80%): 5
|
||||
|
||||
## SKILL CANDIDATES
|
||||
1. Cluster: "adding tests"
|
||||
Instincts: 3
|
||||
Avg confidence: 82%
|
||||
Domains: testing
|
||||
Scopes: project
|
||||
|
||||
## COMMAND CANDIDATES (2)
|
||||
/adding-tests
|
||||
From: test-first-workflow [project]
|
||||
Confidence: 84%
|
||||
|
||||
## AGENT CANDIDATES (1)
|
||||
adding-tests-agent
|
||||
Covers 3 instincts
|
||||
Avg confidence: 82%
|
||||
```
|
||||
|
||||
## Bayraklar
|
||||
|
||||
- `--generate`: Analiz çıktısına ek olarak evrimleşmiş dosyaları oluştur
|
||||
|
||||
## Oluşturulan Dosya Formatı
|
||||
|
||||
### Command
|
||||
```markdown
|
||||
---
|
||||
name: new-table
|
||||
description: Migration, şema güncellemesi ve tip oluşturma ile yeni veritabanı tablosu oluştur
|
||||
command: /new-table
|
||||
evolved_from:
|
||||
- new-table-migration
|
||||
- update-schema
|
||||
- regenerate-types
|
||||
---
|
||||
|
||||
# New Table Command
|
||||
|
||||
[Kümelenmiş içgüdülere dayalı oluşturulan içerik]
|
||||
|
||||
## Steps
|
||||
1. ...
|
||||
2. ...
|
||||
```
|
||||
|
||||
### Skill
|
||||
```markdown
|
||||
---
|
||||
name: functional-patterns
|
||||
description: Functional programming pattern'lerini zorla
|
||||
evolved_from:
|
||||
- prefer-functional
|
||||
- use-immutable
|
||||
- avoid-classes
|
||||
---
|
||||
|
||||
# Functional Patterns Skill
|
||||
|
||||
[Kümelenmiş içgüdülere dayalı oluşturulan içerik]
|
||||
```
|
||||
|
||||
### Agent
|
||||
```markdown
|
||||
---
|
||||
name: debugger
|
||||
description: Sistematik debugging agent
|
||||
model: sonnet
|
||||
evolved_from:
|
||||
- debug-check-logs
|
||||
- debug-isolate
|
||||
- debug-reproduce
|
||||
---
|
||||
|
||||
# Debugger Agent
|
||||
|
||||
[Kümelenmiş içgüdülere dayalı oluşturulan içerik]
|
||||
```
|
||||
183
docs/tr/commands/go-build.md
Normal file
183
docs/tr/commands/go-build.md
Normal file
@@ -0,0 +1,183 @@
|
||||
---
|
||||
description: Go build hatalarını, go vet uyarılarını ve linter sorunlarını aşamalı olarak düzelt. Minimal, cerrahi düzeltmeler için go-build-resolver agent'ını çağırır.
|
||||
---
|
||||
|
||||
# Go Build and Fix
|
||||
|
||||
Bu komut, minimal değişikliklerle Go build hatalarını aşamalı olarak düzeltmek için **go-build-resolver** agent'ını çağırır.
|
||||
|
||||
## Bu Komut Ne Yapar
|
||||
|
||||
1. **Diagnostics Çalıştır**: `go build`, `go vet`, `staticcheck` yürüt
|
||||
2. **Hataları Parse Et**: Dosyaya göre grupla ve önem derecesine göre sırala
|
||||
3. **Aşamalı Düzelt**: Bir seferde bir hata
|
||||
4. **Her Düzeltmeyi Doğrula**: Her değişiklikten sonra build'i yeniden çalıştır
|
||||
5. **Özet Raporla**: Neyin düzeltildiğini ve neyin kaldığını göster
|
||||
|
||||
## Ne Zaman Kullanılır
|
||||
|
||||
`/go-build` komutunu şu durumlarda kullanın:
|
||||
- `go build ./...` hatalarla başarısız olduğunda
|
||||
- `go vet ./...` sorunlar raporladığında
|
||||
- `golangci-lint run` uyarılar gösterdiğinde
|
||||
- Modül bağımlılıkları bozulduğunda
|
||||
- Build'i bozan değişiklikleri pull ettikten sonra
|
||||
|
||||
## Çalıştırılan Diagnostic Komutları
|
||||
|
||||
```bash
|
||||
# Birincil build kontrolü
|
||||
go build ./...
|
||||
|
||||
# Static analiz
|
||||
go vet ./...
|
||||
|
||||
# Genişletilmiş linting (mevcutsa)
|
||||
staticcheck ./...
|
||||
golangci-lint run
|
||||
|
||||
# Modül sorunları
|
||||
go mod verify
|
||||
go mod tidy -v
|
||||
```
|
||||
|
||||
## Örnek Oturum
|
||||
|
||||
```text
|
||||
Kullanıcı: /go-build
|
||||
|
||||
Agent:
|
||||
# Go Build Çözümü
|
||||
|
||||
## İlk Diagnostics
|
||||
|
||||
```bash
|
||||
$ go build ./...
|
||||
internal/service/user.go:25:15: undefined: UserRepository
|
||||
internal/handler/api.go:42:9: cannot use x (type string) as type int
|
||||
internal/handler/api.go:58:2: missing return at end of function
|
||||
```
|
||||
|
||||
Bulunan hatalar: 3
|
||||
|
||||
## Düzeltme 1: Tanımsız Tanımlayıcı
|
||||
|
||||
Dosya: internal/service/user.go:25
|
||||
Hata: undefined: UserRepository
|
||||
Neden: Eksik import
|
||||
|
||||
```go
|
||||
// Import eklendi
|
||||
import "project/internal/repository"
|
||||
|
||||
// Değiştirildi
|
||||
var repo UserRepository
|
||||
// Şuna
|
||||
var repo repository.UserRepository
|
||||
```
|
||||
|
||||
```bash
|
||||
$ go build ./...
|
||||
# 2 hata kaldı
|
||||
```
|
||||
|
||||
## Düzeltme 2: Tip Uyuşmazlığı
|
||||
|
||||
Dosya: internal/handler/api.go:42
|
||||
Hata: cannot use x (type string) as type int
|
||||
|
||||
```go
|
||||
// Değiştirildi
|
||||
count := params.Get("count")
|
||||
// Şuna
|
||||
countStr := params.Get("count")
|
||||
count, _ := strconv.Atoi(countStr)
|
||||
```
|
||||
|
||||
```bash
|
||||
$ go build ./...
|
||||
# 1 hata kaldı
|
||||
```
|
||||
|
||||
## Düzeltme 3: Eksik Return
|
||||
|
||||
Dosya: internal/handler/api.go:58
|
||||
Hata: missing return at end of function
|
||||
|
||||
```go
|
||||
func GetUser(id string) (*User, error) {
|
||||
if id == "" {
|
||||
return nil, ErrInvalidID
|
||||
}
|
||||
user := findUser(id)
|
||||
// Eksik return eklendi
|
||||
return user, nil
|
||||
}
|
||||
```
|
||||
|
||||
```bash
|
||||
$ go build ./...
|
||||
# Build başarılı!
|
||||
```
|
||||
|
||||
## Son Doğrulama
|
||||
|
||||
```bash
|
||||
$ go vet ./...
|
||||
# Sorun yok
|
||||
|
||||
$ go test ./...
|
||||
ok project/internal/service 0.015s
|
||||
ok project/internal/handler 0.023s
|
||||
```
|
||||
|
||||
## Özet
|
||||
|
||||
| Metrik | Sayı |
|
||||
|--------|-------|
|
||||
| Düzeltilen build hataları | 3 |
|
||||
| Düzeltilen vet uyarıları | 0 |
|
||||
| Değiştirilen dosyalar | 2 |
|
||||
| Kalan sorunlar | 0 |
|
||||
|
||||
Build Durumu: ✅ BAŞARILI
|
||||
```
|
||||
|
||||
## Düzeltilen Yaygın Hatalar
|
||||
|
||||
| Hata | Tipik Düzeltme |
|
||||
|-------|-------------|
|
||||
| `undefined: X` | Import ekle veya yazım hatasını düzelt |
|
||||
| `cannot use X as Y` | Tip dönüşümü veya atamayı düzelt |
|
||||
| `missing return` | Return ifadesi ekle |
|
||||
| `X does not implement Y` | Eksik metod ekle |
|
||||
| `import cycle` | Paketleri yeniden yapılandır |
|
||||
| `declared but not used` | Değişkeni kaldır veya kullan |
|
||||
| `cannot find package` | `go get` veya `go mod tidy` |
|
||||
|
||||
## Düzeltme Stratejisi
|
||||
|
||||
1. **Önce build hataları** - Kodun compile edilmesi gerekli
|
||||
2. **İkinci olarak vet uyarıları** - Şüpheli yapıları düzelt
|
||||
3. **Üçüncü olarak lint uyarıları** - Stil ve en iyi uygulamalar
|
||||
4. **Bir seferde bir düzeltme** - Her değişikliği doğrula
|
||||
5. **Minimal değişiklikler** - Refactor etme, sadece düzelt
|
||||
|
||||
## Durdurma Koşulları
|
||||
|
||||
Agent şu durumlarda durur ve raporlar:
|
||||
- Aynı hata 3 denemeden sonra devam ederse
|
||||
- Düzeltme daha fazla hata oluşturursa
|
||||
- Mimari değişiklikler gerektirirse
|
||||
- Harici bağımlılıklar eksikse
|
||||
|
||||
## İlgili Komutlar
|
||||
|
||||
- `/go-test` - Build başarılı olduktan sonra testleri çalıştır
|
||||
- `/go-review` - Kod kalitesini incele
|
||||
- `/verify` - Tam doğrulama döngüsü
|
||||
|
||||
## İlgili
|
||||
|
||||
- Agent: `agents/go-build-resolver.md`
|
||||
- Skill: `skills/golang-patterns/`
|
||||
148
docs/tr/commands/go-review.md
Normal file
148
docs/tr/commands/go-review.md
Normal file
@@ -0,0 +1,148 @@
|
||||
---
|
||||
description: İdiomatic desenler, eşzamanlılık güvenliği, hata yönetimi ve güvenlik için kapsamlı Go kod incelemesi. go-reviewer agent'ını çağırır.
|
||||
---
|
||||
|
||||
# Go Code Review
|
||||
|
||||
Bu komut, Go'ya özel kapsamlı kod incelemesi için **go-reviewer** agent'ını çağırır.
|
||||
|
||||
## Bu Komut Ne Yapar
|
||||
|
||||
1. **Go Değişikliklerini Tanımla**: `git diff` ile değiştirilmiş `.go` dosyalarını bul
|
||||
2. **Static Analiz Çalıştır**: `go vet`, `staticcheck` ve `golangci-lint` yürüt
|
||||
3. **Güvenlik Taraması**: SQL injection, command injection, race condition'ları kontrol et
|
||||
4. **Eşzamanlılık İncelemesi**: Goroutine güvenliğini, channel kullanımını, mutex desenlerini analiz et
|
||||
5. **İdiomatic Go Kontrolü**: Kodun Go kurallarına ve en iyi uygulamalara uyduğunu doğrula
|
||||
6. **Rapor Oluştur**: Sorunları önem derecesine göre kategorize et
|
||||
|
||||
## Ne Zaman Kullanılır
|
||||
|
||||
`/go-review` komutunu şu durumlarda kullanın:
|
||||
- Go kodu yazdıktan veya değiştirdikten sonra
|
||||
- Go değişikliklerini commit etmeden önce
|
||||
- Go kodu içeren pull request'leri incelerken
|
||||
- Yeni bir Go kod tabanına adapte olurken
|
||||
- İdiomatic Go desenlerini öğrenirken
|
||||
|
||||
## İnceleme Kategorileri
|
||||
|
||||
### KRİTİK (Düzeltilmeli)
|
||||
- SQL/Command injection açıklıkları
|
||||
- Senkronizasyon olmadan race condition'lar
|
||||
- Goroutine sızıntıları
|
||||
- Hardcode edilmiş kimlik bilgileri
|
||||
- Güvenli olmayan pointer kullanımı
|
||||
- Kritik yollarda göz ardı edilen hatalar
|
||||
|
||||
### YÜKSEK (Düzeltilmeli)
|
||||
- Bağlamlı hata sarmalama eksikliği
|
||||
- Hata dönüşleri yerine panic
|
||||
- Context yayılmıyor
|
||||
- Deadlock'a neden olan buffersız channel'lar
|
||||
- Interface yerine getirilmeme hataları
|
||||
- Eksik mutex koruması
|
||||
|
||||
### ORTA (Düşünün)
|
||||
- İdiomatic olmayan kod desenleri
|
||||
- Export edilen elementlerde eksik godoc yorumları
|
||||
- Verimsiz string birleştirme
|
||||
- Preallocate edilmemiş slice
|
||||
- Table-driven testler kullanılmamış
|
||||
|
||||
## Çalıştırılan Otomatik Kontroller
|
||||
|
||||
```bash
|
||||
# Static analiz
|
||||
go vet ./...
|
||||
|
||||
# Gelişmiş kontroller (kuruluysa)
|
||||
staticcheck ./...
|
||||
golangci-lint run
|
||||
|
||||
# Race tespiti
|
||||
go build -race ./...
|
||||
|
||||
# Güvenlik açıklıkları
|
||||
govulncheck ./...
|
||||
```
|
||||
|
||||
## Örnek Kullanım
|
||||
|
||||
```text
|
||||
Kullanıcı: /go-review
|
||||
|
||||
Agent:
|
||||
# Go Kod İnceleme Raporu
|
||||
|
||||
## İncelenen Dosyalar
|
||||
- internal/handler/user.go (değiştirildi)
|
||||
- internal/service/auth.go (değiştirildi)
|
||||
|
||||
## Static Analiz Sonuçları
|
||||
✓ go vet: Sorun yok
|
||||
✓ staticcheck: Sorun yok
|
||||
|
||||
## Bulunan Sorunlar
|
||||
|
||||
[KRİTİK] Race Condition
|
||||
Dosya: internal/service/auth.go:45
|
||||
Sorun: Paylaşılan map senkronizasyon olmadan erişiliyor
|
||||
```go
|
||||
var cache = map[string]*Session{} // Eşzamanlı erişim!
|
||||
|
||||
func GetSession(id string) *Session {
|
||||
return cache[id] // Race condition
|
||||
}
|
||||
```
|
||||
Düzeltme: sync.RWMutex veya sync.Map kullan
|
||||
```go
|
||||
var (
|
||||
cache = map[string]*Session{}
|
||||
cacheMu sync.RWMutex
|
||||
)
|
||||
|
||||
func GetSession(id string) *Session {
|
||||
cacheMu.RLock()
|
||||
defer cacheMu.RUnlock()
|
||||
return cache[id]
|
||||
}
|
||||
```
|
||||
|
||||
[YÜKSEK] Eksik Hata Bağlamı
|
||||
Dosya: internal/handler/user.go:28
|
||||
Sorun: Hata bağlam olmadan döndürülüyor
|
||||
```go
|
||||
return err // Bağlam yok
|
||||
```
|
||||
Düzeltme: Bağlamla sarmala
|
||||
```go
|
||||
return fmt.Errorf("get user %s: %w", userID, err)
|
||||
```
|
||||
|
||||
## Özet
|
||||
- KRİTİK: 1
|
||||
- YÜKSEK: 1
|
||||
- ORTA: 0
|
||||
|
||||
Öneri: ❌ KRİTİK sorun düzeltilene kadar merge'i engelle
|
||||
```
|
||||
|
||||
## Onay Kriterleri
|
||||
|
||||
| Durum | Koşul |
|
||||
|--------|-----------|
|
||||
| ✅ Onayla | KRİTİK veya YÜKSEK sorun yok |
|
||||
| ⚠️ Uyarı | Sadece ORTA sorunlar (dikkatle merge et) |
|
||||
| ❌ Engelle | KRİTİK veya YÜKSEK sorun bulundu |
|
||||
|
||||
## Diğer Komutlarla Entegrasyon
|
||||
|
||||
- Testlerin geçtiğinden emin olmak için önce `/go-test` kullanın
|
||||
- Build hataları oluşursa `/go-build` kullanın
|
||||
- Commit etmeden önce `/go-review` kullanın
|
||||
- Go'ya özel olmayan endişeler için `/code-review` kullanın
|
||||
|
||||
## İlgili
|
||||
|
||||
- Agent: `agents/go-reviewer.md`
|
||||
- Skills: `skills/golang-patterns/`, `skills/golang-testing/`
|
||||
268
docs/tr/commands/go-test.md
Normal file
268
docs/tr/commands/go-test.md
Normal file
@@ -0,0 +1,268 @@
|
||||
---
|
||||
description: Go için TDD iş akışını zorlar. Önce table-driven testler yaz, sonra uygula. go test -cover ile %80+ kapsama doğrula.
|
||||
---
|
||||
|
||||
# Go TDD Komutu
|
||||
|
||||
Bu komut, idiomatic Go test desenlerini kullanarak Go kodu için test odaklı geliştirme metodolojisini zorlar.
|
||||
|
||||
## Bu Komut Ne Yapar
|
||||
|
||||
1. **Tipleri/Interface'leri Tanımla**: Önce fonksiyon imzalarını tasarla
|
||||
2. **Table-Driven Testler Yaz**: Kapsamlı test senaryoları oluştur (RED)
|
||||
3. **Testleri Çalıştır**: Testlerin doğru sebepten başarısız olduğunu doğrula
|
||||
4. **Kodu Uygula**: Geçmek için minimal kod yaz (GREEN)
|
||||
5. **Refactor Et**: Testleri yeşil tutarken iyileştir
|
||||
6. **Kapsama Kontrol Et**: %80+ kapsama sağla
|
||||
|
||||
## Ne Zaman Kullanılır
|
||||
|
||||
`/go-test` komutunu şu durumlarda kullanın:
|
||||
- Yeni Go fonksiyonları uygularken
|
||||
- Mevcut koda test kapsama eklerken
|
||||
- Hataları düzeltirken (önce başarısız test yaz)
|
||||
- Kritik iş mantığı oluştururken
|
||||
- Go'da TDD iş akışını öğrenirken
|
||||
|
||||
## TDD Döngüsü
|
||||
|
||||
```
|
||||
RED → Başarısız table-driven test yaz
|
||||
GREEN → Geçmek için minimal kod uygula
|
||||
REFACTOR → Kodu iyileştir, testler yeşil kalsın
|
||||
TEKRARLA → Sonraki test senaryosu
|
||||
```
|
||||
|
||||
## Örnek Oturum
|
||||
|
||||
````
|
||||
Kullanıcı: /go-test E-posta adreslerini doğrulamak için bir fonksiyona ihtiyacım var
|
||||
|
||||
Agent:
|
||||
# TDD Oturumu: E-posta Doğrulayıcı
|
||||
|
||||
## Adım 1: Interface Tanımla
|
||||
|
||||
```go
|
||||
// validator/email.go
|
||||
package validator
|
||||
|
||||
// ValidateEmail verilen string'in geçerli bir e-posta adresi olup olmadığını kontrol eder.
|
||||
// Geçerliyse nil, aksi takdirde sorunu açıklayan hata döndürür.
|
||||
func ValidateEmail(email string) error {
|
||||
panic("not implemented")
|
||||
}
|
||||
```
|
||||
|
||||
## Adım 2: Table-Driven Testler Yaz (RED)
|
||||
|
||||
```go
|
||||
// validator/email_test.go
|
||||
package validator
|
||||
|
||||
import (
|
||||
"testing"
|
||||
)
|
||||
|
||||
func TestValidateEmail(t *testing.T) {
|
||||
tests := []struct {
|
||||
name string
|
||||
email string
|
||||
wantErr bool
|
||||
}{
|
||||
// Geçerli e-postalar
|
||||
{"basit e-posta", "user@example.com", false},
|
||||
{"subdomain ile", "user@mail.example.com", false},
|
||||
{"artı ile", "user+tag@example.com", false},
|
||||
{"noktalar ile", "first.last@example.com", false},
|
||||
|
||||
// Geçersiz e-postalar
|
||||
{"boş string", "", true},
|
||||
{"at işareti yok", "userexample.com", true},
|
||||
{"domain yok", "user@", true},
|
||||
{"local kısım yok", "@example.com", true},
|
||||
{"çift at", "user@@example.com", true},
|
||||
{"boşluklar", "user @example.com", true},
|
||||
{"tld yok", "user@example", true},
|
||||
}
|
||||
|
||||
for _, tt := range tests {
|
||||
t.Run(tt.name, func(t *testing.T) {
|
||||
err := ValidateEmail(tt.email)
|
||||
if tt.wantErr && err == nil {
|
||||
t.Errorf("ValidateEmail(%q) = nil; hata bekleniyor", tt.email)
|
||||
}
|
||||
if !tt.wantErr && err != nil {
|
||||
t.Errorf("ValidateEmail(%q) = %v; nil bekleniyor", tt.email, err)
|
||||
}
|
||||
})
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Adım 3: Testleri Çalıştır - Başarısızlığı Doğrula
|
||||
|
||||
```bash
|
||||
$ go test ./validator/...
|
||||
|
||||
--- FAIL: TestValidateEmail (0.00s)
|
||||
--- FAIL: TestValidateEmail/basit_e-posta (0.00s)
|
||||
panic: not implemented
|
||||
|
||||
FAIL
|
||||
```
|
||||
|
||||
✓ Testler beklendiği gibi başarısız (panic).
|
||||
|
||||
## Adım 4: Minimal Kod Uygula (GREEN)
|
||||
|
||||
```go
|
||||
// validator/email.go
|
||||
package validator
|
||||
|
||||
import (
|
||||
"errors"
|
||||
"regexp"
|
||||
)
|
||||
|
||||
var emailRegex = regexp.MustCompile(`^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$`)
|
||||
|
||||
var (
|
||||
ErrEmailEmpty = errors.New("e-posta boş olamaz")
|
||||
ErrEmailInvalid = errors.New("e-posta formatı geçersiz")
|
||||
)
|
||||
|
||||
func ValidateEmail(email string) error {
|
||||
if email == "" {
|
||||
return ErrEmailEmpty
|
||||
}
|
||||
if !emailRegex.MatchString(email) {
|
||||
return ErrEmailInvalid
|
||||
}
|
||||
return nil
|
||||
}
|
||||
```
|
||||
|
||||
## Adım 5: Testleri Çalıştır - Başarıyı Doğrula
|
||||
|
||||
```bash
|
||||
$ go test ./validator/...
|
||||
|
||||
PASS
|
||||
ok project/validator 0.003s
|
||||
```
|
||||
|
||||
✓ Tüm testler geçiyor!
|
||||
|
||||
## Adım 6: Kapsama Kontrol Et
|
||||
|
||||
```bash
|
||||
$ go test -cover ./validator/...
|
||||
|
||||
PASS
|
||||
coverage: 100.0% of statements
|
||||
ok project/validator 0.003s
|
||||
```
|
||||
|
||||
✓ Kapsama: 100%
|
||||
|
||||
## TDD Tamamlandı!
|
||||
````
|
||||
|
||||
## Test Desenleri
|
||||
|
||||
### Table-Driven Testler
|
||||
```go
|
||||
tests := []struct {
|
||||
name string
|
||||
input InputType
|
||||
want OutputType
|
||||
wantErr bool
|
||||
}{
|
||||
{"senaryo 1", input1, want1, false},
|
||||
{"senaryo 2", input2, want2, true},
|
||||
}
|
||||
|
||||
for _, tt := range tests {
|
||||
t.Run(tt.name, func(t *testing.T) {
|
||||
got, err := Function(tt.input)
|
||||
// assertion'lar
|
||||
})
|
||||
}
|
||||
```
|
||||
|
||||
### Paralel Testler
|
||||
```go
|
||||
for _, tt := range tests {
|
||||
tt := tt // Yakala
|
||||
t.Run(tt.name, func(t *testing.T) {
|
||||
t.Parallel()
|
||||
// test gövdesi
|
||||
})
|
||||
}
|
||||
```
|
||||
|
||||
### Test Yardımcıları
|
||||
```go
|
||||
func setupTestDB(t *testing.T) *sql.DB {
|
||||
t.Helper()
|
||||
db := createDB()
|
||||
t.Cleanup(func() { db.Close() })
|
||||
return db
|
||||
}
|
||||
```
|
||||
|
||||
## Kapsama Komutları
|
||||
|
||||
```bash
|
||||
# Basit kapsama
|
||||
go test -cover ./...
|
||||
|
||||
# Kapsama profili
|
||||
go test -coverprofile=coverage.out ./...
|
||||
|
||||
# Tarayıcıda görüntüle
|
||||
go tool cover -html=coverage.out
|
||||
|
||||
# Fonksiyona göre kapsama
|
||||
go tool cover -func=coverage.out
|
||||
|
||||
# Race tespiti ile
|
||||
go test -race -cover ./...
|
||||
```
|
||||
|
||||
## Kapsama Hedefleri
|
||||
|
||||
| Kod Türü | Hedef |
|
||||
|-----------|--------|
|
||||
| Kritik iş mantığı | 100% |
|
||||
| Public API'ler | 90%+ |
|
||||
| Genel kod | 80%+ |
|
||||
| Oluşturulan kod | Hariç tut |
|
||||
|
||||
## TDD En İyi Uygulamaları
|
||||
|
||||
**YAPIN:**
|
||||
- Herhangi bir uygulamadan ÖNCE test yaz
|
||||
- Her değişiklikten sonra testleri çalıştır
|
||||
- Kapsamlı kapsama için table-driven testler kullan
|
||||
- Uygulama detaylarını değil, davranışı test et
|
||||
- Edge case'leri dahil et (boş, nil, maksimum değerler)
|
||||
|
||||
**YAPMAYIN:**
|
||||
- Testlerden önce uygulama yazma
|
||||
- RED aşamasını atlama
|
||||
- Private fonksiyonları doğrudan test etme
|
||||
- Testlerde `time.Sleep` kullanma
|
||||
- Dengesiz testleri görmezden gelme
|
||||
|
||||
## İlgili Komutlar
|
||||
|
||||
- `/go-build` - Build hatalarını düzelt
|
||||
- `/go-review` - Uygulamadan sonra kodu incele
|
||||
- `/verify` - Tam doğrulama döngüsünü çalıştır
|
||||
|
||||
## İlgili
|
||||
|
||||
- Skill: `skills/golang-testing/`
|
||||
- Skill: `skills/tdd-workflow/`
|
||||
66
docs/tr/commands/instinct-export.md
Normal file
66
docs/tr/commands/instinct-export.md
Normal file
@@ -0,0 +1,66 @@
|
||||
---
|
||||
name: instinct-export
|
||||
description: İçgüdüleri proje/global kapsamdan bir dosyaya aktar
|
||||
command: /instinct-export
|
||||
---
|
||||
|
||||
# Instinct Export Komutu
|
||||
|
||||
İçgüdüleri paylaşılabilir bir formata aktarır. Şunlar için mükemmel:
|
||||
- Takım arkadaşlarıyla paylaşmak
|
||||
- Yeni bir makineye aktarmak
|
||||
- Proje konvansiyonlarına katkıda bulunmak
|
||||
|
||||
## Kullanım
|
||||
|
||||
```
|
||||
/instinct-export # Tüm kişisel içgüdüleri dışa aktar
|
||||
/instinct-export --domain testing # Sadece testing içgüdülerini dışa aktar
|
||||
/instinct-export --min-confidence 0.7 # Sadece yüksek güvenli içgüdüleri dışa aktar
|
||||
/instinct-export --output team-instincts.yaml
|
||||
/instinct-export --scope project --output project-instincts.yaml
|
||||
```
|
||||
|
||||
## Yapılacaklar
|
||||
|
||||
1. Mevcut proje bağlamını tespit et
|
||||
2. Seçilen kapsama göre içgüdüleri yükle:
|
||||
- `project`: sadece mevcut proje
|
||||
- `global`: sadece global
|
||||
- `all`: proje + global birleştirilmiş (varsayılan)
|
||||
3. Filtreleri uygula (`--domain`, `--min-confidence`)
|
||||
4. YAML formatında dosyaya yaz (veya çıktı yolu verilmediyse stdout'a)
|
||||
|
||||
## Çıktı Formatı
|
||||
|
||||
Bir YAML dosyası oluşturur:
|
||||
|
||||
```yaml
|
||||
# Instincts Export
|
||||
# Generated: 2025-01-22
|
||||
# Source: personal
|
||||
# Count: 12 instincts
|
||||
|
||||
---
|
||||
id: prefer-functional-style
|
||||
trigger: "when writing new functions"
|
||||
confidence: 0.8
|
||||
domain: code-style
|
||||
source: session-observation
|
||||
scope: project
|
||||
project_id: a1b2c3d4e5f6
|
||||
project_name: my-app
|
||||
---
|
||||
|
||||
# Prefer Functional Style
|
||||
|
||||
## Action
|
||||
Use functional patterns over classes.
|
||||
```
|
||||
|
||||
## Bayraklar
|
||||
|
||||
- `--domain <name>`: Sadece belirtilen domain'i dışa aktar
|
||||
- `--min-confidence <n>`: Minimum güven eşiği
|
||||
- `--output <file>`: Çıktı dosya yolu (atlandığında stdout'a yazdırır)
|
||||
- `--scope <project|global|all>`: Dışa aktarma kapsamı (varsayılan: `all`)
|
||||
114
docs/tr/commands/instinct-import.md
Normal file
114
docs/tr/commands/instinct-import.md
Normal file
@@ -0,0 +1,114 @@
|
||||
---
|
||||
name: instinct-import
|
||||
description: İçgüdüleri dosya veya URL'den proje/global kapsama aktar
|
||||
command: true
|
||||
---
|
||||
|
||||
# Instinct Import Komutu
|
||||
|
||||
## Uygulama
|
||||
|
||||
Plugin root path kullanarak instinct CLI'ı çalıştır:
|
||||
|
||||
```bash
|
||||
python3 "${CLAUDE_PLUGIN_ROOT}/skills/continuous-learning-v2/scripts/instinct-cli.py" import <file-or-url> [--dry-run] [--force] [--min-confidence 0.7] [--scope project|global]
|
||||
```
|
||||
|
||||
Veya `CLAUDE_PLUGIN_ROOT` ayarlanmamışsa (manuel kurulum):
|
||||
|
||||
```bash
|
||||
python3 ~/.claude/skills/continuous-learning-v2/scripts/instinct-cli.py import <file-or-url>
|
||||
```
|
||||
|
||||
Yerel dosya yollarından veya HTTP(S) URL'lerinden içgüdüleri içe aktar.
|
||||
|
||||
## Kullanım
|
||||
|
||||
```
|
||||
/instinct-import team-instincts.yaml
|
||||
/instinct-import https://raw.githubusercontent.com/org/repo/main/instincts.yaml
|
||||
/instinct-import team-instincts.yaml --dry-run
|
||||
/instinct-import team-instincts.yaml --scope global --force
|
||||
```
|
||||
|
||||
## Yapılacaklar
|
||||
|
||||
1. İçgüdü dosyasını al (yerel yol veya URL)
|
||||
2. Formatı doğrula ve ayrıştır
|
||||
3. Mevcut içgüdülerle duplikasyon kontrolü yap
|
||||
4. Yeni içgüdüleri birleştir veya ekle
|
||||
5. İçgüdüleri inherited dizinine kaydet:
|
||||
- Proje kapsamı: `~/.claude/homunculus/projects/<project-id>/instincts/inherited/`
|
||||
- Global kapsam: `~/.claude/homunculus/instincts/inherited/`
|
||||
|
||||
## İçe Aktarma İşlemi
|
||||
|
||||
```
|
||||
📥 Importing instincts from: team-instincts.yaml
|
||||
================================================
|
||||
|
||||
Found 12 instincts to import.
|
||||
|
||||
Analyzing conflicts...
|
||||
|
||||
## New Instincts (8)
|
||||
These will be added:
|
||||
✓ use-zod-validation (confidence: 0.7)
|
||||
✓ prefer-named-exports (confidence: 0.65)
|
||||
✓ test-async-functions (confidence: 0.8)
|
||||
...
|
||||
|
||||
## Duplicate Instincts (3)
|
||||
Already have similar instincts:
|
||||
⚠️ prefer-functional-style
|
||||
Local: 0.8 confidence, 12 observations
|
||||
Import: 0.7 confidence
|
||||
→ Keep local (higher confidence)
|
||||
|
||||
⚠️ test-first-workflow
|
||||
Local: 0.75 confidence
|
||||
Import: 0.9 confidence
|
||||
→ Update to import (higher confidence)
|
||||
|
||||
Import 8 new, update 1?
|
||||
```
|
||||
|
||||
## Birleştirme Davranışı
|
||||
|
||||
Mevcut ID'ye sahip bir içgüdü içe aktarılırken:
|
||||
- Daha yüksek güvenli içe aktarma güncelleme adayı olur
|
||||
- Eşit/düşük güvenli içe aktarma atlanır
|
||||
- `--force` kullanılmadıkça kullanıcı onaylar
|
||||
|
||||
## Kaynak İzleme
|
||||
|
||||
İçe aktarılan içgüdüler şu şekilde işaretlenir:
|
||||
```yaml
|
||||
source: inherited
|
||||
scope: project
|
||||
imported_from: "team-instincts.yaml"
|
||||
project_id: "a1b2c3d4e5f6"
|
||||
project_name: "my-project"
|
||||
```
|
||||
|
||||
## Bayraklar
|
||||
|
||||
- `--dry-run`: İçe aktarmadan önizle
|
||||
- `--force`: Onay istemini atla
|
||||
- `--min-confidence <n>`: Sadece eşiğin üzerindeki içgüdüleri içe aktar
|
||||
- `--scope <project|global>`: Hedef kapsamı seç (varsayılan: `project`)
|
||||
|
||||
## Çıktı
|
||||
|
||||
İçe aktarma sonrası:
|
||||
```
|
||||
✅ Import complete!
|
||||
|
||||
Added: 8 instincts
|
||||
Updated: 1 instinct
|
||||
Skipped: 3 instincts (equal/higher confidence already exists)
|
||||
|
||||
New instincts saved to: ~/.claude/homunculus/instincts/inherited/
|
||||
|
||||
Run /instinct-status to see all instincts.
|
||||
```
|
||||
59
docs/tr/commands/instinct-status.md
Normal file
59
docs/tr/commands/instinct-status.md
Normal file
@@ -0,0 +1,59 @@
|
||||
---
|
||||
name: instinct-status
|
||||
description: Öğrenilen içgüdüleri (proje + global) güven seviyesiyle göster
|
||||
command: true
|
||||
---
|
||||
|
||||
# Instinct Status Komutu
|
||||
|
||||
Mevcut proje için öğrenilen içgüdüleri ve global içgüdüleri, domain'e göre gruplandırılmış şekilde gösterir.
|
||||
|
||||
## Uygulama
|
||||
|
||||
Plugin root path kullanarak instinct CLI'ı çalıştır:
|
||||
|
||||
```bash
|
||||
python3 "${CLAUDE_PLUGIN_ROOT}/skills/continuous-learning-v2/scripts/instinct-cli.py" status
|
||||
```
|
||||
|
||||
Veya `CLAUDE_PLUGIN_ROOT` ayarlanmamışsa (manuel kurulum):
|
||||
|
||||
```bash
|
||||
python3 ~/.claude/skills/continuous-learning-v2/scripts/instinct-cli.py status
|
||||
```
|
||||
|
||||
## Kullanım
|
||||
|
||||
```
|
||||
/instinct-status
|
||||
```
|
||||
|
||||
## Yapılacaklar
|
||||
|
||||
1. Mevcut proje bağlamını tespit et (git remote/path hash)
|
||||
2. `~/.claude/homunculus/projects/<project-id>/instincts/` konumundan proje içgüdülerini oku
|
||||
3. `~/.claude/homunculus/instincts/` konumundan global içgüdüleri oku
|
||||
4. Öncelik kurallarıyla birleştir (ID çakışmasında proje global'i geçersiz kılar)
|
||||
5. Domain'e göre gruplandırılmış, güven çubukları ve gözlem istatistikleriyle göster
|
||||
|
||||
## Çıktı Formatı
|
||||
|
||||
```
|
||||
============================================================
|
||||
INSTINCT STATUS - 12 total
|
||||
============================================================
|
||||
|
||||
Project: my-app (a1b2c3d4e5f6)
|
||||
Project instincts: 8
|
||||
Global instincts: 4
|
||||
|
||||
## PROJECT-SCOPED (my-app)
|
||||
### WORKFLOW (3)
|
||||
███████░░░ 70% grep-before-edit [project]
|
||||
trigger: when modifying code
|
||||
|
||||
## GLOBAL (apply to all projects)
|
||||
### SECURITY (2)
|
||||
█████████░ 85% validate-user-input [global]
|
||||
trigger: when handling user input
|
||||
```
|
||||
116
docs/tr/commands/learn-eval.md
Normal file
116
docs/tr/commands/learn-eval.md
Normal file
@@ -0,0 +1,116 @@
|
||||
---
|
||||
description: "Oturumdan yeniden kullanılabilir desenleri çıkar, kaydetmeden önce kaliteyi kendinden değerlendir ve doğru kayıt konumunu belirle (Global vs Proje)."
|
||||
---
|
||||
|
||||
# /learn-eval - Çıkar, Değerlendir, Sonra Kaydet
|
||||
|
||||
Herhangi bir skill dosyası yazmadan önce kalite kontrolü, kayıt konumu kararı ve bilgi yerleşimi farkındalığı ile `/learn`'ü genişletir.
|
||||
|
||||
## Ne Çıkarılmalı
|
||||
|
||||
Şunları arayın:
|
||||
|
||||
1. **Hata Çözüm Desenleri** — kök neden + düzeltme + yeniden kullanılabilirlik
|
||||
2. **Hata Ayıklama Teknikleri** — bariz olmayan adımlar, araç kombinasyonları
|
||||
3. **Geçici Çözümler** — kütüphane gariplikleri, API sınırlamaları, versiyona özel düzeltmeler
|
||||
4. **Projeye Özgü Desenler** — kurallar, mimari kararlar, entegrasyon desenleri
|
||||
|
||||
## Süreç
|
||||
|
||||
1. Çıkarılabilir desenler için oturumu incele
|
||||
2. En değerli/yeniden kullanılabilir içgörüyü tanımla
|
||||
|
||||
3. **Kayıt konumunu belirle:**
|
||||
- Sor: "Bu desen farklı bir projede faydalı olur mu?"
|
||||
- **Global** (`~/.claude/skills/learned/`): 2+ projede kullanılabilir genel desenler (bash uyumluluğu, LLM API davranışı, hata ayıklama teknikleri, vb.)
|
||||
- **Proje** (mevcut projedeki `.claude/skills/learned/`): Projeye özel bilgi (belirli bir config dosyasının gariplikleri, projeye özel mimari kararlar, vb.)
|
||||
- Emin değilseniz, Global seçin (Global → Proje taşımak tersinden daha kolay)
|
||||
|
||||
4. Bu formatı kullanarak skill dosyasını taslak olarak hazırla:
|
||||
|
||||
```markdown
|
||||
---
|
||||
name: desen-adi
|
||||
description: "130 karakterin altında"
|
||||
user-invocable: false
|
||||
origin: auto-extracted
|
||||
---
|
||||
|
||||
# [Açıklayıcı Desen Adı]
|
||||
|
||||
**Çıkarıldı:** [Tarih]
|
||||
**Bağlam:** [Bunun ne zaman geçerli olduğunun kısa açıklaması]
|
||||
|
||||
## Sorun
|
||||
[Bunun çözdüğü sorun - spesifik olun]
|
||||
|
||||
## Çözüm
|
||||
[Desen/teknik/geçici çözüm - kod örnekleriyle]
|
||||
|
||||
## Ne Zaman Kullanılır
|
||||
[Tetikleyici koşullar]
|
||||
```
|
||||
|
||||
5. **Kalite kontrolü — Kontrol listesi + Bütünsel karar**
|
||||
|
||||
### 5a. Gerekli kontrol listesi (dosyaları gerçekten okuyarak doğrula)
|
||||
|
||||
Taslağı değerlendirmeden önce **tümünü** yürüt:
|
||||
|
||||
- [ ] İçerik örtüşmesini kontrol etmek için anahtar kelimeyle `~/.claude/skills/` ve ilgili proje `.claude/skills/` dosyalarını Grep ile ara
|
||||
- [ ] Örtüşme için MEMORY.md'yi kontrol et (hem proje hem de global)
|
||||
- [ ] Mevcut bir skill'e eklemenin yeterli olup olmayacağını düşün
|
||||
- [ ] Bunun yeniden kullanılabilir bir desen olduğunu, tek seferlik bir düzeltme olmadığını onayla
|
||||
|
||||
### 5b. Bütünsel karar
|
||||
|
||||
Kontrol listesi sonuçlarını ve taslak kalitesini sentezle, sonra şunlardan **birini** seç:
|
||||
|
||||
| Karar | Anlam | Sonraki Aksiyon |
|
||||
|---------|---------|-------------|
|
||||
| **Kaydet** | Benzersiz, spesifik, iyi kapsamlı | Adım 6'ya geç |
|
||||
| **İyileştir sonra Kaydet** | Değerli ama iyileştirme gerekiyor | İyileştirmeleri listele → revize et → yeniden değerlendir (bir kez) |
|
||||
| **[X]'e Ekle** | Mevcut bir skill'e eklenmelidir | Hedef skill'i ve eklemeleri göster → Adım 6 |
|
||||
| **Düşür** | Önemsiz, gereksiz veya çok soyut | Gerekçeyi açıkla ve dur |
|
||||
|
||||
**Yönlendirici boyutlar** (karar verirken, puanlanmaz):
|
||||
|
||||
- **Spesifiklik ve Uygulanabilirlik**: Hemen kullanılabilir kod örnekleri veya komutlar içerir
|
||||
- **Kapsam Uyumu**: Ad, tetikleyici koşullar ve içerik hizalanmış ve tek bir desene odaklanmış
|
||||
- **Benzersizlik**: Mevcut skill'lerin kapsamadığı değer sağlar (kontrol listesi sonuçlarına göre)
|
||||
- **Yeniden Kullanılabilirlik**: Gelecekteki oturumlarda gerçekçi tetikleyici senaryolar mevcut
|
||||
|
||||
6. **Karara özel onay akışı**
|
||||
|
||||
- **İyileştir sonra Kaydet**: Gerekli iyileştirmeleri + revize edilmiş taslağı + bir yeniden değerlendirmeden sonra güncellenmiş kontrol listesi/kararı sun; revize karar **Kaydet** ise kullanıcı onayından sonra kaydet, aksi takdirde yeni kararı takip et
|
||||
- **Kaydet**: Kayıt yolunu + kontrol listesi sonuçlarını + 1 satırlık karar gerekçesini + tam taslağı sun → kullanıcı onayından sonra kaydet
|
||||
- **[X]'e Ekle**: Hedef yolu + eklemeleri (diff formatında) + kontrol listesi sonuçlarını + karar gerekçesini sun → kullanıcı onayından sonra ekle
|
||||
- **Düşür**: Sadece kontrol listesi sonuçlarını + gerekçeyi göster (onay gerekmiyor)
|
||||
|
||||
7. Belirlenen konuma Kaydet / Ekle
|
||||
|
||||
## Adım 5 için Çıktı Formatı
|
||||
|
||||
```
|
||||
### Kontrol Listesi
|
||||
- [x] skills/ grep: örtüşme yok (veya: örtüşme bulundu → detaylar)
|
||||
- [x] MEMORY.md: örtüşme yok (veya: örtüşme bulundu → detaylar)
|
||||
- [x] Mevcut skill'e ekleme: yeni dosya uygun (veya: [X]'e eklenmeli)
|
||||
- [x] Yeniden kullanılabilirlik: onaylandı (veya: tek seferlik → Düşür)
|
||||
|
||||
### Karar: Kaydet / İyileştir sonra Kaydet / [X]'e Ekle / Düşür
|
||||
|
||||
**Gerekçe:** (Kararı açıklayan 1-2 cümle)
|
||||
```
|
||||
|
||||
## Tasarım Gerekçesi
|
||||
|
||||
Bu versiyon, önceki 5 boyutlu sayısal puanlama rubriğini (Spesifiklik, Uygulanabilirlik, Kapsam Uyumu, Gereksizlik Olmama, Kapsama 1-5 arası puanlanıyor) kontrol listesi tabanlı bütünsel karar sistemiyle değiştirir. Modern frontier modeller (Opus 4.6+) güçlü bağlamsal yargıya sahiptir — zengin niteliksel sinyalleri sayısal skorlara zorlamak nüans kaybettirir ve yanıltıcı toplamlar üretebilir. Bütünsel yaklaşım, modelin tüm faktörleri doğal olarak tartmasına izin vererek daha doğru kaydet/düşür kararları üretirken, açık kontrol listesi kritik hiçbir kontrolün atlanmamasını sağlar.
|
||||
|
||||
## Notlar
|
||||
|
||||
- Önemsiz düzeltmeleri çıkarmayın (yazım hataları, basit sözdizimi hataları)
|
||||
- Tek seferlik sorunları çıkarmayın (belirli API kesintileri, vb.)
|
||||
- Gelecekteki oturumlarda zaman kazandıracak desenlere odaklanın
|
||||
- Skill'leri odaklı tutun — skill başına bir desen
|
||||
- Karar Ekle olduğunda, yeni dosya oluşturmak yerine mevcut skill'e ekleyin
|
||||
70
docs/tr/commands/learn.md
Normal file
70
docs/tr/commands/learn.md
Normal file
@@ -0,0 +1,70 @@
|
||||
# /learn - Yeniden Kullanılabilir Desenleri Çıkar
|
||||
|
||||
Mevcut oturumu analiz et ve skill olarak kaydetmeye değer desenleri çıkar.
|
||||
|
||||
## Tetikleyici
|
||||
|
||||
Önemsiz olmayan bir sorunu çözdüğünüzde, oturum sırasında herhangi bir noktada `/learn` komutunu çalıştırın.
|
||||
|
||||
## Ne Çıkarılmalı
|
||||
|
||||
Şunları arayın:
|
||||
|
||||
1. **Hata Çözüm Desenleri**
|
||||
- Hangi hata oluştu?
|
||||
- Kök neden neydi?
|
||||
- Onu ne düzeltti?
|
||||
- Bu benzer hatalar için yeniden kullanılabilir mi?
|
||||
|
||||
2. **Hata Ayıklama Teknikleri**
|
||||
- Bariz olmayan hata ayıklama adımları
|
||||
- İşe yarayan araç kombinasyonları
|
||||
- Tanılama desenleri
|
||||
|
||||
3. **Geçici Çözümler**
|
||||
- Kütüphane gariplikleri
|
||||
- API sınırlamaları
|
||||
- Versiyona özel düzeltmeler
|
||||
|
||||
4. **Projeye Özgü Desenler**
|
||||
- Keşfedilen kod tabanı kuralları
|
||||
- Verilen mimari kararlar
|
||||
- Entegrasyon desenleri
|
||||
|
||||
## Çıktı Formatı
|
||||
|
||||
`~/.claude/skills/learned/[desen-adi].md` konumunda bir skill dosyası oluştur:
|
||||
|
||||
```markdown
|
||||
# [Açıklayıcı Desen Adı]
|
||||
|
||||
**Çıkarıldı:** [Tarih]
|
||||
**Bağlam:** [Bunun ne zaman geçerli olduğunun kısa açıklaması]
|
||||
|
||||
## Sorun
|
||||
[Bunun çözdüğü sorun - spesifik olun]
|
||||
|
||||
## Çözüm
|
||||
[Desen/teknik/geçici çözüm]
|
||||
|
||||
## Örnek
|
||||
[Uygulanabilirse kod örneği]
|
||||
|
||||
## Ne Zaman Kullanılır
|
||||
[Tetikleyici koşullar - bu skill'i neyin etkinleştirmesi gerektiği]
|
||||
```
|
||||
|
||||
## Süreç
|
||||
|
||||
1. Çıkarılabilir desenler için oturumu incele
|
||||
2. En değerli/yeniden kullanılabilir içgörüyü tanımla
|
||||
3. Skill dosyasını taslak olarak hazırla
|
||||
4. Kaydetmeden önce kullanıcıdan onay iste
|
||||
5. `~/.claude/skills/learned/` konumuna kaydet
|
||||
|
||||
## Notlar
|
||||
|
||||
- Önemsiz düzeltmeleri çıkarmayın (yazım hataları, basit sözdizimi hataları)
|
||||
- Tek seferlik sorunları çıkarmayın (belirli API kesintileri, vb.)
|
||||
- Gelecekteki oturumlarda zaman kazandıracak desenlere odaklanın
|
||||
- Skill'leri odaklı tutun - skill başına bir desen
|
||||
158
docs/tr/commands/multi-backend.md
Normal file
158
docs/tr/commands/multi-backend.md
Normal file
@@ -0,0 +1,158 @@
|
||||
# Backend - Backend Odaklı Geliştirme
|
||||
|
||||
Backend odaklı iş akışı (Research → Ideation → Plan → Execute → Optimize → Review), Codex liderliğinde.
|
||||
|
||||
## Kullanım
|
||||
|
||||
```bash
|
||||
/backend <backend task açıklaması>
|
||||
```
|
||||
|
||||
## Context
|
||||
|
||||
- Backend task: $ARGUMENTS
|
||||
- Codex liderliğinde, Gemini yardımcı referans için
|
||||
- Uygulanabilir: API tasarımı, algoritma implementasyonu, veritabanı optimizasyonu, business logic
|
||||
|
||||
## Rolünüz
|
||||
|
||||
**Backend Orkestratör**sünüz, sunucu tarafı görevler için multi-model işbirliğini koordine ediyorsunuz (Research → Ideation → Plan → Execute → Optimize → Review).
|
||||
|
||||
**İşbirlikçi Modeller**:
|
||||
- **Codex** – Backend logic, algoritmalar (**Backend otoritesi, güvenilir**)
|
||||
- **Gemini** – Frontend perspektifi (**Backend görüşleri sadece referans için**)
|
||||
- **Claude (self)** – Orkestrasyon, planlama, execution, teslimat
|
||||
|
||||
---
|
||||
|
||||
## Multi-Model Çağrı Spesifikasyonu
|
||||
|
||||
**Çağrı Sözdizimi**:
|
||||
|
||||
```
|
||||
# Yeni session çağrısı
|
||||
Bash({
|
||||
command: "~/.claude/bin/codeagent-wrapper {{LITE_MODE_FLAG}}--backend codex - \"$PWD\" <<'EOF'
|
||||
ROLE_FILE: <role prompt path>
|
||||
<TASK>
|
||||
Requirement: <enhanced requirement (veya enhance edilmediyse $ARGUMENTS)>
|
||||
Context: <önceki fazlardan proje context'i ve analiz>
|
||||
</TASK>
|
||||
OUTPUT: Expected output format
|
||||
EOF",
|
||||
run_in_background: false,
|
||||
timeout: 3600000,
|
||||
description: "Brief description"
|
||||
})
|
||||
|
||||
# Session devam ettirme çağrısı
|
||||
Bash({
|
||||
command: "~/.claude/bin/codeagent-wrapper {{LITE_MODE_FLAG}}--backend codex resume <SESSION_ID> - \"$PWD\" <<'EOF'
|
||||
ROLE_FILE: <role prompt path>
|
||||
<TASK>
|
||||
Requirement: <enhanced requirement (veya enhance edilmediyse $ARGUMENTS)>
|
||||
Context: <önceki fazlardan proje context'i ve analiz>
|
||||
</TASK>
|
||||
OUTPUT: Expected output format
|
||||
EOF",
|
||||
run_in_background: false,
|
||||
timeout: 3600000,
|
||||
description: "Brief description"
|
||||
})
|
||||
```
|
||||
|
||||
**Role Prompts**:
|
||||
|
||||
| Phase | Codex |
|
||||
|-------|-------|
|
||||
| Analysis | `~/.claude/.ccg/prompts/codex/analyzer.md` |
|
||||
| Planning | `~/.claude/.ccg/prompts/codex/architect.md` |
|
||||
| Review | `~/.claude/.ccg/prompts/codex/reviewer.md` |
|
||||
|
||||
**Session Reuse**: Her çağrı `SESSION_ID: xxx` döndürür, sonraki fazlar için `resume xxx` kullan. Phase 2'de `CODEX_SESSION` kaydet, Phase 3 ve 5'te `resume` kullan.
|
||||
|
||||
---
|
||||
|
||||
## İletişim Yönergeleri
|
||||
|
||||
1. Yanıtlara mode etiketi `[Mode: X]` ile başla, ilk `[Mode: Research]`
|
||||
2. Katı sıra takip et: `Research → Ideation → Plan → Execute → Optimize → Review`
|
||||
3. Gerektiğinde kullanıcı etkileşimi için `AskUserQuestion` tool kullan (örn., onay/seçim/approval)
|
||||
|
||||
---
|
||||
|
||||
## Ana İş Akışı
|
||||
|
||||
### Phase 0: Prompt Enhancement (İsteğe Bağlı)
|
||||
|
||||
`[Mode: Prepare]` - ace-tool MCP mevcutsa, `mcp__ace-tool__enhance_prompt` çağır, **orijinal $ARGUMENTS'ı sonraki Codex çağrıları için enhanced sonuçla değiştir**. Mevcut değilse, `$ARGUMENTS`'ı olduğu gibi kullan.
|
||||
|
||||
### Phase 1: Research
|
||||
|
||||
`[Mode: Research]` - Requirement'ları anla ve context topla
|
||||
|
||||
1. **Code Retrieval** (ace-tool MCP mevcutsa): Mevcut API'leri, veri modellerini, servis mimarisini almak için `mcp__ace-tool__search_context` çağır. Mevcut değilse, built-in tool'ları kullan: dosya keşfi için `Glob`, sembol/API araması için `Grep`, context toplama için `Read`, daha derin keşif için `Task` (Explore agent).
|
||||
2. Requirement tamamlılık skoru (0-10): >=7 devam et, <7 dur ve tamamla
|
||||
|
||||
### Phase 2: Ideation
|
||||
|
||||
`[Mode: Ideation]` - Codex liderliğinde analiz
|
||||
|
||||
**Codex'i MUTLAKA çağır** (yukarıdaki çağrı spesifikasyonunu takip et):
|
||||
- ROLE_FILE: `~/.claude/.ccg/prompts/codex/analyzer.md`
|
||||
- Requirement: Enhanced requirement (veya enhance edilmediyse $ARGUMENTS)
|
||||
- Context: Phase 1'den proje context'i
|
||||
- OUTPUT: Teknik fizibilite analizi, önerilen çözümler (en az 2), risk değerlendirmesi
|
||||
|
||||
**SESSION_ID'yi kaydet** (`CODEX_SESSION`) sonraki faz yeniden kullanımı için.
|
||||
|
||||
Çözümleri çıktıla (en az 2), kullanıcı seçimini bekle.
|
||||
|
||||
### Phase 3: Planning
|
||||
|
||||
`[Mode: Plan]` - Codex liderliğinde planlama
|
||||
|
||||
**Codex'i MUTLAKA çağır** (session'ı yeniden kullanmak için `resume <CODEX_SESSION>` kullan):
|
||||
- ROLE_FILE: `~/.claude/.ccg/prompts/codex/architect.md`
|
||||
- Requirement: Kullanıcının seçtiği çözüm
|
||||
- Context: Phase 2'den analiz sonuçları
|
||||
- OUTPUT: Dosya yapısı, fonksiyon/sınıf tasarımı, bağımlılık ilişkileri
|
||||
|
||||
Claude planı sentezler, kullanıcı onayından sonra `.claude/plan/task-name.md`'ye kaydet.
|
||||
|
||||
### Phase 4: Implementation
|
||||
|
||||
`[Mode: Execute]` - Kod geliştirme
|
||||
|
||||
- Onaylanan planı kesinlikle takip et
|
||||
- Mevcut proje kod standartlarını takip et
|
||||
- Hata işleme, güvenlik, performans optimizasyonu sağla
|
||||
|
||||
### Phase 5: Optimization
|
||||
|
||||
`[Mode: Optimize]` - Codex liderliğinde review
|
||||
|
||||
**Codex'i MUTLAKA çağır** (yukarıdaki çağrı spesifikasyonunu takip et):
|
||||
- ROLE_FILE: `~/.claude/.ccg/prompts/codex/reviewer.md`
|
||||
- Requirement: Aşağıdaki backend kod değişikliklerini incele
|
||||
- Context: git diff veya kod içeriği
|
||||
- OUTPUT: Güvenlik, performans, hata işleme, API uyumu sorunlar listesi
|
||||
|
||||
Review geri bildirimlerini entegre et, kullanıcı onayından sonra optimizasyonu çalıştır.
|
||||
|
||||
### Phase 6: Quality Review
|
||||
|
||||
`[Mode: Review]` - Nihai değerlendirme
|
||||
|
||||
- Plana karşı tamamlılığı kontrol et
|
||||
- Fonksiyonaliteyi doğrulamak için test'leri çalıştır
|
||||
- Sorunları ve önerileri raporla
|
||||
|
||||
---
|
||||
|
||||
## Ana Kurallar
|
||||
|
||||
1. **Codex backend görüşleri güvenilir**
|
||||
2. **Gemini backend görüşleri sadece referans için**
|
||||
3. Harici modellerin **sıfır dosya sistemi yazma erişimi**
|
||||
4. Claude tüm kod yazma ve dosya operasyonlarını yönetir
|
||||
315
docs/tr/commands/multi-execute.md
Normal file
315
docs/tr/commands/multi-execute.md
Normal file
@@ -0,0 +1,315 @@
|
||||
# Execute - Multi-Model İşbirlikçi Execution
|
||||
|
||||
Multi-model işbirlikçi execution - Plandan prototype al → Claude refactor edip implement eder → Multi-model audit ve teslimat.
|
||||
|
||||
$ARGUMENTS
|
||||
|
||||
---
|
||||
|
||||
## Ana Protokoller
|
||||
|
||||
- **Dil Protokolü**: Tool/model'lerle etkileşimde **İngilizce** kullan, kullanıcıyla kendi dilinde iletişim kur
|
||||
- **Kod Egemenliği**: Harici modellerin **sıfır dosya sistemi yazma erişimi**, tüm değişiklikler Claude tarafından
|
||||
- **Dirty Prototype Refactoring**: Codex/Gemini Unified Diff'i "dirty prototype" olarak değerlendir, production-grade koda refactor edilmeli
|
||||
- **Stop-Loss Mekanizması**: Mevcut faz çıktısı doğrulanana kadar bir sonraki faza geçme
|
||||
- **Ön Koşul**: Sadece kullanıcı `/ccg:plan` çıktısına açıkça "Y" cevabı verdikten sonra çalıştır (eksikse, önce onay al)
|
||||
|
||||
---
|
||||
|
||||
## Multi-Model Çağrı Spesifikasyonu
|
||||
|
||||
**Çağrı Sözdizimi** (parallel: `run_in_background: true` kullan):
|
||||
|
||||
```
|
||||
# Session devam ettirme çağrısı (önerilen) - Implementation Prototype
|
||||
Bash({
|
||||
command: "~/.claude/bin/codeagent-wrapper {{LITE_MODE_FLAG}}--backend <codex|gemini> {{GEMINI_MODEL_FLAG}}resume <SESSION_ID> - \"$PWD\" <<'EOF'
|
||||
ROLE_FILE: <role prompt path>
|
||||
<TASK>
|
||||
Requirement: <task description>
|
||||
Context: <plan content + target files>
|
||||
</TASK>
|
||||
OUTPUT: Unified Diff Patch ONLY. Strictly prohibit any actual modifications.
|
||||
EOF",
|
||||
run_in_background: true,
|
||||
timeout: 3600000,
|
||||
description: "Brief description"
|
||||
})
|
||||
|
||||
# Yeni session çağrısı - Implementation Prototype
|
||||
Bash({
|
||||
command: "~/.claude/bin/codeagent-wrapper {{LITE_MODE_FLAG}}--backend <codex|gemini> {{GEMINI_MODEL_FLAG}}- \"$PWD\" <<'EOF'
|
||||
ROLE_FILE: <role prompt path>
|
||||
<TASK>
|
||||
Requirement: <task description>
|
||||
Context: <plan content + target files>
|
||||
</TASK>
|
||||
OUTPUT: Unified Diff Patch ONLY. Strictly prohibit any actual modifications.
|
||||
EOF",
|
||||
run_in_background: true,
|
||||
timeout: 3600000,
|
||||
description: "Brief description"
|
||||
})
|
||||
```
|
||||
|
||||
**Audit Çağrı Sözdizimi** (Code Review / Audit):
|
||||
|
||||
```
|
||||
Bash({
|
||||
command: "~/.claude/bin/codeagent-wrapper {{LITE_MODE_FLAG}}--backend <codex|gemini> {{GEMINI_MODEL_FLAG}}resume <SESSION_ID> - \"$PWD\" <<'EOF'
|
||||
ROLE_FILE: <role prompt path>
|
||||
<TASK>
|
||||
Scope: Audit the final code changes.
|
||||
Inputs:
|
||||
- The applied patch (git diff / final unified diff)
|
||||
- The touched files (relevant excerpts if needed)
|
||||
Constraints:
|
||||
- Do NOT modify any files.
|
||||
- Do NOT output tool commands that assume filesystem access.
|
||||
</TASK>
|
||||
OUTPUT:
|
||||
1) A prioritized list of issues (severity, file, rationale)
|
||||
2) Concrete fixes; if code changes are needed, include a Unified Diff Patch in a fenced code block.
|
||||
EOF",
|
||||
run_in_background: true,
|
||||
timeout: 3600000,
|
||||
description: "Brief description"
|
||||
})
|
||||
```
|
||||
|
||||
**Model Parametre Notları**:
|
||||
- `{{GEMINI_MODEL_FLAG}}`: `--backend gemini` kullanırken, `--gemini-model gemini-3-pro-preview` ile değiştir (trailing space not edin); codex için boş string kullan
|
||||
|
||||
**Role Prompts**:
|
||||
|
||||
| Phase | Codex | Gemini |
|
||||
|-------|-------|--------|
|
||||
| Implementation | `~/.claude/.ccg/prompts/codex/architect.md` | `~/.claude/.ccg/prompts/gemini/frontend.md` |
|
||||
| Review | `~/.claude/.ccg/prompts/codex/reviewer.md` | `~/.claude/.ccg/prompts/gemini/reviewer.md` |
|
||||
|
||||
**Session Reuse**: `/ccg:plan` SESSION_ID sağladıysa, context'i yeniden kullanmak için `resume <SESSION_ID>` kullan.
|
||||
|
||||
**Background Task'leri Bekle** (max timeout 600000ms = 10 dakika):
|
||||
|
||||
```
|
||||
TaskOutput({ task_id: "<task_id>", block: true, timeout: 600000 })
|
||||
```
|
||||
|
||||
**ÖNEMLİ**:
|
||||
- `timeout: 600000` belirtilmeli, aksi takdirde varsayılan 30 saniye erken timeout'a neden olur
|
||||
- 10 dakika sonra hala tamamlanmamışsa, `TaskOutput` ile polling'e devam et, **ASLA process'i öldürme**
|
||||
- Bekleme timeout nedeniyle atlanırsa, **MUTLAKA `AskUserQuestion` çağırarak kullanıcıya beklemeye devam etmek veya task'i öldürmek isteyip istemediğini sor**
|
||||
|
||||
---
|
||||
|
||||
## Execution Workflow
|
||||
|
||||
**Execute Task**: $ARGUMENTS
|
||||
|
||||
### Phase 0: Planı Oku
|
||||
|
||||
`[Mode: Prepare]`
|
||||
|
||||
1. **Input Tipini Tanımla**:
|
||||
- Plan dosya yolu (örn., `.claude/plan/xxx.md`)
|
||||
- Doğrudan task açıklaması
|
||||
|
||||
2. **Plan İçeriğini Oku**:
|
||||
- Plan dosya yolu sağlandıysa, oku ve ayrıştır
|
||||
- Çıkar: task tipi, implementation adımları, anahtar dosyalar, SESSION_ID
|
||||
|
||||
3. **Pre-Execution Onayı**:
|
||||
- Input "doğrudan task açıklaması" veya plan `SESSION_ID` / anahtar dosyalar eksikse: önce kullanıcıyla onay al
|
||||
- Kullanıcının plana "Y" cevabı verdiğini onaylayamazsan: devam etmeden önce tekrar onay al
|
||||
|
||||
4. **Task Tipi Routing**:
|
||||
|
||||
| Task Type | Detection | Route |
|
||||
|-----------|-----------|-------|
|
||||
| **Frontend** | Pages, components, UI, styles, layout | Gemini |
|
||||
| **Backend** | API, interfaces, database, logic, algorithms | Codex |
|
||||
| **Fullstack** | Hem frontend hem de backend içerir | Codex ∥ Gemini parallel |
|
||||
|
||||
---
|
||||
|
||||
### Phase 1: Hızlı Context Retrieval
|
||||
|
||||
`[Mode: Retrieval]`
|
||||
|
||||
**ace-tool MCP mevcutsa**, hızlı context retrieval için kullan:
|
||||
|
||||
Plandaki "Key Files" listesine göre, `mcp__ace-tool__search_context` çağır:
|
||||
|
||||
```
|
||||
mcp__ace-tool__search_context({
|
||||
query: "<plan içeriğine dayalı semantik sorgu, anahtar dosyalar, modüller, fonksiyon adları dahil>",
|
||||
project_root_path: "$PWD"
|
||||
})
|
||||
```
|
||||
|
||||
**Retrieval Stratejisi**:
|
||||
- Planın "Key Files" tablosundan hedef yolları çıkar
|
||||
- Semantik sorgu oluştur: giriş dosyaları, bağımlılık modülleri, ilgili tip tanımları
|
||||
- Sonuçlar yetersizse, 1-2 recursive retrieval ekle
|
||||
|
||||
**ace-tool MCP mevcut DEĞİLSE**, fallback olarak Claude Code built-in tool'ları kullan:
|
||||
1. **Glob**: Planın "Key Files" tablosundan hedef dosyaları bul (örn., `Glob("src/components/**/*.tsx")`)
|
||||
2. **Grep**: Codebase genelinde anahtar semboller, fonksiyon adları, tip tanımlarını ara
|
||||
3. **Read**: Tam context toplamak için keşfedilen dosyaları oku
|
||||
4. **Task (Explore agent)**: Daha geniş keşif için, `Task`'ı `subagent_type: "Explore"` ile kullan
|
||||
|
||||
**Retrieval Sonrası**:
|
||||
- Alınan kod snippet'lerini organize et
|
||||
- Implementation için tam context'i onayla
|
||||
- Phase 3'e geç
|
||||
|
||||
---
|
||||
|
||||
### Phase 3: Prototype Edinimi
|
||||
|
||||
`[Mode: Prototype]`
|
||||
|
||||
**Task Tipine Göre Route Et**:
|
||||
|
||||
#### Route A: Frontend/UI/Styles → Gemini
|
||||
|
||||
**Limit**: Context < 32k token
|
||||
|
||||
1. Gemini'yi çağır (`~/.claude/.ccg/prompts/gemini/frontend.md` kullan)
|
||||
2. Input: Plan içeriği + alınan context + hedef dosyalar
|
||||
3. OUTPUT: `Unified Diff Patch ONLY. Strictly prohibit any actual modifications.`
|
||||
4. **Gemini frontend tasarım otoritesidir, CSS/React/Vue prototype'ı nihai görsel temeldir**
|
||||
5. **UYARI**: Gemini'nin backend logic önerilerini yoksay
|
||||
6. Plan `GEMINI_SESSION` içeriyorsa: `resume <GEMINI_SESSION>` tercih et
|
||||
|
||||
#### Route B: Backend/Logic/Algorithms → Codex
|
||||
|
||||
1. Codex'i çağır (`~/.claude/.ccg/prompts/codex/architect.md` kullan)
|
||||
2. Input: Plan içeriği + alınan context + hedef dosyalar
|
||||
3. OUTPUT: `Unified Diff Patch ONLY. Strictly prohibit any actual modifications.`
|
||||
4. **Codex backend logic otoritesidir, mantıksal akıl yürütme ve debug yeteneklerinden faydalan**
|
||||
5. Plan `CODEX_SESSION` içeriyorsa: `resume <CODEX_SESSION>` tercih et
|
||||
|
||||
#### Route C: Fullstack → Parallel Çağrılar
|
||||
|
||||
1. **Parallel Çağrılar** (`run_in_background: true`):
|
||||
- Gemini: Frontend kısmını ele al
|
||||
- Codex: Backend kısmını ele al
|
||||
2. `TaskOutput` ile her iki modelin tam sonuçlarını bekle
|
||||
3. Her biri `resume` için plandan ilgili `SESSION_ID`'yi kullanır (eksikse yeni session oluştur)
|
||||
|
||||
**Yukarıdaki `Multi-Model Çağrı Spesifikasyonu`'ndaki `ÖNEMLİ` talimatları takip et**
|
||||
|
||||
---
|
||||
|
||||
### Phase 4: Code Implementation
|
||||
|
||||
`[Mode: Implement]`
|
||||
|
||||
**Kod Egemenliği olarak Claude şu adımları çalıştırır**:
|
||||
|
||||
1. **Diff Oku**: Codex/Gemini'nin döndürdüğü Unified Diff Patch'i ayrıştır
|
||||
|
||||
2. **Mental Sandbox**:
|
||||
- Diff'in hedef dosyalara uygulanmasını simüle et
|
||||
- Mantıksal tutarlılığı kontrol et
|
||||
- Potansiyel çakışmaları veya yan etkileri tanımla
|
||||
|
||||
3. **Refactor ve Temizle**:
|
||||
- "Dirty prototype"'ı **yüksek okunabilir, sürdürülebilir, enterprise-grade koda** refactor et
|
||||
- Gereksiz kodu kaldır
|
||||
- Projenin mevcut kod standartlarına uygunluğu sağla
|
||||
- **Gerekli olmadıkça yorum/doküman oluşturma**, kod kendi kendini açıklamalı
|
||||
|
||||
4. **Minimal Kapsam**:
|
||||
- Değişiklikler sadece requirement kapsamıyla sınırlı
|
||||
- Yan etkiler için **zorunlu gözden geçirme**
|
||||
- Hedefli düzeltmeler yap
|
||||
|
||||
5. **Değişiklikleri Uygula**:
|
||||
- Gerçek değişiklikleri çalıştırmak için Edit/Write tool'larını kullan
|
||||
- **Sadece gerekli kodu değiştir**, kullanıcının diğer mevcut fonksiyonlarını asla etkileme
|
||||
|
||||
6. **Self-Verification** (şiddetle önerilir):
|
||||
- Projenin mevcut lint / typecheck / test'lerini çalıştır (minimal ilgili kapsama öncelik ver)
|
||||
- Başarısız olursa: önce regresyonları düzelt, sonra Phase 5'e geç
|
||||
|
||||
---
|
||||
|
||||
### Phase 5: Audit ve Teslimat
|
||||
|
||||
`[Mode: Audit]`
|
||||
|
||||
#### 5.1 Otomatik Audit
|
||||
|
||||
**Değişiklikler yürürlüğe girdikten sonra, MUTLAKA hemen parallel call** Codex ve Gemini'yi Code Review için:
|
||||
|
||||
1. **Codex Review** (`run_in_background: true`):
|
||||
- ROLE_FILE: `~/.claude/.ccg/prompts/codex/reviewer.md`
|
||||
- Input: Değiştirilen Diff + hedef dosyalar
|
||||
- Odak: Güvenlik, performans, hata işleme, logic doğruluğu
|
||||
|
||||
2. **Gemini Review** (`run_in_background: true`):
|
||||
- ROLE_FILE: `~/.claude/.ccg/prompts/gemini/reviewer.md`
|
||||
- Input: Değiştirilen Diff + hedef dosyalar
|
||||
- Odak: Erişilebilirlik, tasarım tutarlılığı, kullanıcı deneyimi
|
||||
|
||||
`TaskOutput` ile her iki modelin tam review sonuçlarını bekle. Context tutarlılığı için Phase 3 session'larını yeniden kullanmayı tercih et (`resume <SESSION_ID>`).
|
||||
|
||||
#### 5.2 Entegre Et ve Düzelt
|
||||
|
||||
1. Codex + Gemini review geri bildirimlerini sentezle
|
||||
2. Güven kurallarına göre değerlendir: Backend Codex'i takip eder, Frontend Gemini'yi takip eder
|
||||
3. Gerekli düzeltmeleri çalıştır
|
||||
4. Gerektiğinde Phase 5.1'i tekrarla (risk kabul edilebilir olana kadar)
|
||||
|
||||
#### 5.3 Teslimat Onayı
|
||||
|
||||
Audit geçtikten sonra, kullanıcıya rapor et:
|
||||
|
||||
```markdown
|
||||
## Execution Complete
|
||||
|
||||
### Change Summary
|
||||
| File | Operation | Description |
|
||||
|------|-----------|-------------|
|
||||
| path/to/file.ts | Modified | Description |
|
||||
|
||||
### Audit Results
|
||||
- Codex: <Passed/Found N issues>
|
||||
- Gemini: <Passed/Found N issues>
|
||||
|
||||
### Recommendations
|
||||
1. [ ] <Önerilen test adımları>
|
||||
2. [ ] <Önerilen doğrulama adımları>
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Ana Kurallar
|
||||
|
||||
1. **Kod Egemenliği** – Tüm dosya değişiklikleri Claude tarafından, harici modellerin sıfır yazma erişimi
|
||||
2. **Dirty Prototype Refactoring** – Codex/Gemini çıktısı taslak olarak değerlendirilir, refactor edilmeli
|
||||
3. **Güven Kuralları** – Backend Codex'i takip eder, Frontend Gemini'yi takip eder
|
||||
4. **Minimal Değişiklikler** – Sadece gerekli kodu değiştir, yan etki yok
|
||||
5. **Zorunlu Audit** – Değişikliklerden sonra multi-model Code Review yapılmalı
|
||||
|
||||
---
|
||||
|
||||
## Kullanım
|
||||
|
||||
```bash
|
||||
# Plan dosyasını çalıştır
|
||||
/ccg:execute .claude/plan/feature-name.md
|
||||
|
||||
# Task'i doğrudan çalıştır (context'te zaten tartışılmış planlar için)
|
||||
/ccg:execute implement user authentication based on previous plan
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## /ccg:plan ile İlişki
|
||||
|
||||
1. `/ccg:plan` plan + SESSION_ID oluşturur
|
||||
2. Kullanıcı "Y" ile onaylar
|
||||
3. `/ccg:execute` planı okur, SESSION_ID'yi yeniden kullanır, implementation'ı çalıştırır
|
||||
158
docs/tr/commands/multi-frontend.md
Normal file
158
docs/tr/commands/multi-frontend.md
Normal file
@@ -0,0 +1,158 @@
|
||||
# Frontend - Frontend Odaklı Geliştirme
|
||||
|
||||
Frontend odaklı iş akışı (Research → Ideation → Plan → Execute → Optimize → Review), Gemini liderliğinde.
|
||||
|
||||
## Kullanım
|
||||
|
||||
```bash
|
||||
/frontend <UI task açıklaması>
|
||||
```
|
||||
|
||||
## Context
|
||||
|
||||
- Frontend task: $ARGUMENTS
|
||||
- Gemini liderliğinde, Codex yardımcı referans için
|
||||
- Uygulanabilir: Component tasarımı, responsive layout, UI animasyonları, stil optimizasyonu
|
||||
|
||||
## Rolünüz
|
||||
|
||||
**Frontend Orkestratör**sünüz, UI/UX görevleri için multi-model işbirliğini koordine ediyorsunuz (Research → Ideation → Plan → Execute → Optimize → Review).
|
||||
|
||||
**İşbirlikçi Modeller**:
|
||||
- **Gemini** – Frontend UI/UX (**Frontend otoritesi, güvenilir**)
|
||||
- **Codex** – Backend perspektifi (**Frontend görüşleri sadece referans için**)
|
||||
- **Claude (self)** – Orkestrasyon, planlama, execution, teslimat
|
||||
|
||||
---
|
||||
|
||||
## Multi-Model Çağrı Spesifikasyonu
|
||||
|
||||
**Çağrı Sözdizimi**:
|
||||
|
||||
```
|
||||
# Yeni session çağrısı
|
||||
Bash({
|
||||
command: "~/.claude/bin/codeagent-wrapper {{LITE_MODE_FLAG}}--backend gemini --gemini-model gemini-3-pro-preview - \"$PWD\" <<'EOF'
|
||||
ROLE_FILE: <role prompt path>
|
||||
<TASK>
|
||||
Requirement: <enhanced requirement (veya enhance edilmediyse $ARGUMENTS)>
|
||||
Context: <önceki fazlardan proje context'i ve analiz>
|
||||
</TASK>
|
||||
OUTPUT: Expected output format
|
||||
EOF",
|
||||
run_in_background: false,
|
||||
timeout: 3600000,
|
||||
description: "Brief description"
|
||||
})
|
||||
|
||||
# Session devam ettirme çağrısı
|
||||
Bash({
|
||||
command: "~/.claude/bin/codeagent-wrapper {{LITE_MODE_FLAG}}--backend gemini --gemini-model gemini-3-pro-preview resume <SESSION_ID> - \"$PWD\" <<'EOF'
|
||||
ROLE_FILE: <role prompt path>
|
||||
<TASK>
|
||||
Requirement: <enhanced requirement (veya enhance edilmediyse $ARGUMENTS)>
|
||||
Context: <önceki fazlardan proje context'i ve analiz>
|
||||
</TASK>
|
||||
OUTPUT: Expected output format
|
||||
EOF",
|
||||
run_in_background: false,
|
||||
timeout: 3600000,
|
||||
description: "Brief description"
|
||||
})
|
||||
```
|
||||
|
||||
**Role Prompts**:
|
||||
|
||||
| Phase | Gemini |
|
||||
|-------|--------|
|
||||
| Analysis | `~/.claude/.ccg/prompts/gemini/analyzer.md` |
|
||||
| Planning | `~/.claude/.ccg/prompts/gemini/architect.md` |
|
||||
| Review | `~/.claude/.ccg/prompts/gemini/reviewer.md` |
|
||||
|
||||
**Session Reuse**: Her çağrı `SESSION_ID: xxx` döndürür, sonraki fazlar için `resume xxx` kullan. Phase 2'de `GEMINI_SESSION` kaydet, Phase 3 ve 5'te `resume` kullan.
|
||||
|
||||
---
|
||||
|
||||
## İletişim Yönergeleri
|
||||
|
||||
1. Yanıtlara mode etiketi `[Mode: X]` ile başla, ilk `[Mode: Research]`
|
||||
2. Katı sıra takip et: `Research → Ideation → Plan → Execute → Optimize → Review`
|
||||
3. Gerektiğinde kullanıcı etkileşimi için `AskUserQuestion` tool kullan (örn., onay/seçim/approval)
|
||||
|
||||
---
|
||||
|
||||
## Ana İş Akışı
|
||||
|
||||
### Phase 0: Prompt Enhancement (İsteğe Bağlı)
|
||||
|
||||
`[Mode: Prepare]` - ace-tool MCP mevcutsa, `mcp__ace-tool__enhance_prompt` çağır, **orijinal $ARGUMENTS'ı sonraki Gemini çağrıları için enhanced sonuçla değiştir**. Mevcut değilse, `$ARGUMENTS`'ı olduğu gibi kullan.
|
||||
|
||||
### Phase 1: Research
|
||||
|
||||
`[Mode: Research]` - Requirement'ları anla ve context topla
|
||||
|
||||
1. **Code Retrieval** (ace-tool MCP mevcutsa): Mevcut component'leri, stilleri, tasarım sistemini almak için `mcp__ace-tool__search_context` çağır. Mevcut değilse, built-in tool'ları kullan: dosya keşfi için `Glob`, component/stil araması için `Grep`, context toplama için `Read`, daha derin keşif için `Task` (Explore agent).
|
||||
2. Requirement tamamlılık skoru (0-10): >=7 devam et, <7 dur ve tamamla
|
||||
|
||||
### Phase 2: Ideation
|
||||
|
||||
`[Mode: Ideation]` - Gemini liderliğinde analiz
|
||||
|
||||
**Gemini'yi MUTLAKA çağır** (yukarıdaki çağrı spesifikasyonunu takip et):
|
||||
- ROLE_FILE: `~/.claude/.ccg/prompts/gemini/analyzer.md`
|
||||
- Requirement: Enhanced requirement (veya enhance edilmediyse $ARGUMENTS)
|
||||
- Context: Phase 1'den proje context'i
|
||||
- OUTPUT: UI fizibilite analizi, önerilen çözümler (en az 2), UX değerlendirmesi
|
||||
|
||||
**SESSION_ID'yi kaydet** (`GEMINI_SESSION`) sonraki faz yeniden kullanımı için.
|
||||
|
||||
Çözümleri çıktıla (en az 2), kullanıcı seçimini bekle.
|
||||
|
||||
### Phase 3: Planning
|
||||
|
||||
`[Mode: Plan]` - Gemini liderliğinde planlama
|
||||
|
||||
**Gemini'yi MUTLAKA çağır** (session'ı yeniden kullanmak için `resume <GEMINI_SESSION>` kullan):
|
||||
- ROLE_FILE: `~/.claude/.ccg/prompts/gemini/architect.md`
|
||||
- Requirement: Kullanıcının seçtiği çözüm
|
||||
- Context: Phase 2'den analiz sonuçları
|
||||
- OUTPUT: Component yapısı, UI akışı, stillendirme yaklaşımı
|
||||
|
||||
Claude planı sentezler, kullanıcı onayından sonra `.claude/plan/task-name.md`'ye kaydet.
|
||||
|
||||
### Phase 4: Implementation
|
||||
|
||||
`[Mode: Execute]` - Kod geliştirme
|
||||
|
||||
- Onaylanan planı kesinlikle takip et
|
||||
- Mevcut proje tasarım sistemi ve kod standartlarını takip et
|
||||
- Responsiveness, accessibility sağla
|
||||
|
||||
### Phase 5: Optimization
|
||||
|
||||
`[Mode: Optimize]` - Gemini liderliğinde review
|
||||
|
||||
**Gemini'yi MUTLAKA çağır** (yukarıdaki çağrı spesifikasyonunu takip et):
|
||||
- ROLE_FILE: `~/.claude/.ccg/prompts/gemini/reviewer.md`
|
||||
- Requirement: Aşağıdaki frontend kod değişikliklerini incele
|
||||
- Context: git diff veya kod içeriği
|
||||
- OUTPUT: Accessibility, responsiveness, performans, tasarım tutarlılığı sorunlar listesi
|
||||
|
||||
Review geri bildirimlerini entegre et, kullanıcı onayından sonra optimizasyonu çalıştır.
|
||||
|
||||
### Phase 6: Quality Review
|
||||
|
||||
`[Mode: Review]` - Nihai değerlendirme
|
||||
|
||||
- Plana karşı tamamlılığı kontrol et
|
||||
- Responsiveness ve accessibility doğrula
|
||||
- Sorunları ve önerileri raporla
|
||||
|
||||
---
|
||||
|
||||
## Ana Kurallar
|
||||
|
||||
1. **Gemini frontend görüşleri güvenilir**
|
||||
2. **Codex frontend görüşleri sadece referans için**
|
||||
3. Harici modellerin **sıfır dosya sistemi yazma erişimi**
|
||||
4. Claude tüm kod yazma ve dosya operasyonlarını yönetir
|
||||
268
docs/tr/commands/multi-plan.md
Normal file
268
docs/tr/commands/multi-plan.md
Normal file
@@ -0,0 +1,268 @@
|
||||
# Plan - Multi-Model İşbirlikçi Planlama
|
||||
|
||||
Multi-model işbirlikçi planlama - Context retrieval + Dual-model analiz → Adım adım implementation planı oluştur.
|
||||
|
||||
$ARGUMENTS
|
||||
|
||||
---
|
||||
|
||||
## Ana Protokoller
|
||||
|
||||
- **Dil Protokolü**: Tool/model'lerle etkileşimde **İngilizce** kullan, kullanıcıyla kendi dilinde iletişim kur
|
||||
- **Zorunlu Parallel**: Codex/Gemini çağrıları `run_in_background: true` kullanmalı (ana thread'i bloke etmemek için tek model çağrılarında bile)
|
||||
- **Kod Egemenliği**: Harici modellerin **sıfır dosya sistemi yazma erişimi**, tüm değişiklikler Claude tarafından
|
||||
- **Stop-Loss Mekanizması**: Mevcut faz çıktısı doğrulanana kadar bir sonraki faza geçme
|
||||
- **Sadece Planlama**: Bu komut context okumaya ve `.claude/plan/*` plan dosyalarına yazmaya izin verir, ancak **ASLA production kodu değiştirmez**
|
||||
|
||||
---
|
||||
|
||||
## Multi-Model Çağrı Spesifikasyonu
|
||||
|
||||
**Çağrı Sözdizimi** (parallel: `run_in_background: true` kullan):
|
||||
|
||||
```
|
||||
Bash({
|
||||
command: "~/.claude/bin/codeagent-wrapper {{LITE_MODE_FLAG}}--backend <codex|gemini> {{GEMINI_MODEL_FLAG}}- \"$PWD\" <<'EOF'
|
||||
ROLE_FILE: <role prompt path>
|
||||
<TASK>
|
||||
Requirement: <enhanced requirement>
|
||||
Context: <retrieved project context>
|
||||
</TASK>
|
||||
OUTPUT: Step-by-step implementation plan with pseudo-code. DO NOT modify any files.
|
||||
EOF",
|
||||
run_in_background: true,
|
||||
timeout: 3600000,
|
||||
description: "Brief description"
|
||||
})
|
||||
```
|
||||
|
||||
**Model Parametre Notları**:
|
||||
- `{{GEMINI_MODEL_FLAG}}`: `--backend gemini` kullanırken, `--gemini-model gemini-3-pro-preview` ile değiştir (trailing space not edin); codex için boş string kullan
|
||||
|
||||
**Role Prompts**:
|
||||
|
||||
| Phase | Codex | Gemini |
|
||||
|-------|-------|--------|
|
||||
| Analysis | `~/.claude/.ccg/prompts/codex/analyzer.md` | `~/.claude/.ccg/prompts/gemini/analyzer.md` |
|
||||
| Planning | `~/.claude/.ccg/prompts/codex/architect.md` | `~/.claude/.ccg/prompts/gemini/architect.md` |
|
||||
|
||||
**Session Reuse**: Her çağrı `SESSION_ID: xxx` döndürür (genellikle wrapper tarafından çıktılanır), sonraki `/ccg:execute` kullanımı için **MUTLAKA kaydet**.
|
||||
|
||||
**Background Task'leri Bekle** (max timeout 600000ms = 10 dakika):
|
||||
|
||||
```
|
||||
TaskOutput({ task_id: "<task_id>", block: true, timeout: 600000 })
|
||||
```
|
||||
|
||||
**ÖNEMLİ**:
|
||||
- `timeout: 600000` belirtilmeli, aksi takdirde varsayılan 30 saniye erken timeout'a neden olur
|
||||
- 10 dakika sonra hala tamamlanmamışsa, `TaskOutput` ile polling'e devam et, **ASLA process'i öldürme**
|
||||
- Bekleme timeout nedeniyle atlanırsa, **MUTLAKA `AskUserQuestion` çağırarak kullanıcıya beklemeye devam etmek veya task'i öldürmek isteyip istemediğini sor**
|
||||
|
||||
---
|
||||
|
||||
## Execution Workflow
|
||||
|
||||
**Planlama Görevi**: $ARGUMENTS
|
||||
|
||||
### Phase 1: Tam Context Retrieval
|
||||
|
||||
`[Mode: Research]`
|
||||
|
||||
#### 1.1 Prompt Enhancement (İLK önce çalıştırılmalı)
|
||||
|
||||
**ace-tool MCP mevcutsa**, `mcp__ace-tool__enhance_prompt` tool'unu çağır:
|
||||
|
||||
```
|
||||
mcp__ace-tool__enhance_prompt({
|
||||
prompt: "$ARGUMENTS",
|
||||
conversation_history: "<son 5-10 konuşma turu>",
|
||||
project_root_path: "$PWD"
|
||||
})
|
||||
```
|
||||
|
||||
Enhanced prompt'u bekle, **orijinal $ARGUMENTS'ı tüm sonraki fazlar için enhanced sonuçla değiştir**.
|
||||
|
||||
**ace-tool MCP mevcut DEĞİLSE**: Bu adımı atla ve tüm sonraki fazlar için orijinal `$ARGUMENTS`'ı olduğu gibi kullan.
|
||||
|
||||
#### 1.2 Context Retrieval
|
||||
|
||||
**ace-tool MCP mevcutsa**, `mcp__ace-tool__search_context` tool'unu çağır:
|
||||
|
||||
```
|
||||
mcp__ace-tool__search_context({
|
||||
query: "<enhanced requirement'a dayalı semantik sorgu>",
|
||||
project_root_path: "$PWD"
|
||||
})
|
||||
```
|
||||
|
||||
- Doğal dil kullanarak semantik sorgu oluştur (Where/What/How)
|
||||
- **ASLA varsayımlara dayalı cevap verme**
|
||||
|
||||
**ace-tool MCP mevcut DEĞİLSE**, fallback olarak Claude Code built-in tool'ları kullan:
|
||||
1. **Glob**: Pattern'e göre ilgili dosyaları bul (örn., `Glob("**/*.ts")`, `Glob("src/**/*.py")`)
|
||||
2. **Grep**: Anahtar semboller, fonksiyon adları, sınıf tanımlarını ara (örn., `Grep("className|functionName")`)
|
||||
3. **Read**: Tam context toplamak için keşfedilen dosyaları oku
|
||||
4. **Task (Explore agent)**: Daha derin keşif için, codebase genelinde aramak üzere `Task`'ı `subagent_type: "Explore"` ile kullan
|
||||
|
||||
#### 1.3 Tamamlılık Kontrolü
|
||||
|
||||
- İlgili sınıflar, fonksiyonlar, değişkenler için **tam tanımlar ve imzalar** elde etmeli
|
||||
- Context yetersizse, **recursive retrieval** tetikle
|
||||
- Çıktıya öncelik ver: giriş dosyası + satır numarası + anahtar sembol adı; belirsizliği çözmek için gerekli olduğunda minimal kod snippet'leri ekle
|
||||
|
||||
#### 1.4 Requirement Alignment
|
||||
|
||||
- Requirement'larda hala belirsizlik varsa, kullanıcı için yönlendirici sorular **MUTLAKA** çıktıla
|
||||
- Requirement sınırları net olana kadar (eksiklik yok, fazlalık yok)
|
||||
|
||||
### Phase 2: Multi-Model İşbirlikçi Analiz
|
||||
|
||||
`[Mode: Analysis]`
|
||||
|
||||
#### 2.1 Input'ları Dağıt
|
||||
|
||||
**Parallel call** Codex ve Gemini (`run_in_background: true`):
|
||||
|
||||
**Orijinal requirement**'ı (önceden belirlenmiş görüşler olmadan) her iki modele dağıt:
|
||||
|
||||
1. **Codex Backend Analysis**:
|
||||
- ROLE_FILE: `~/.claude/.ccg/prompts/codex/analyzer.md`
|
||||
- Odak: Teknik fizibilite, mimari etki, performans değerlendirmeleri, potansiyel riskler
|
||||
- OUTPUT: Çok perspektifli çözümler + artı/eksi analizi
|
||||
|
||||
2. **Gemini Frontend Analysis**:
|
||||
- ROLE_FILE: `~/.claude/.ccg/prompts/gemini/analyzer.md`
|
||||
- Odak: UI/UX etkisi, kullanıcı deneyimi, görsel tasarım
|
||||
- OUTPUT: Çok perspektifli çözümler + artı/eksi analizi
|
||||
|
||||
`TaskOutput` ile her iki modelin tam sonuçlarını bekle. **SESSION_ID'yi kaydet** (`CODEX_SESSION` ve `GEMINI_SESSION`).
|
||||
|
||||
#### 2.2 Cross-Validation
|
||||
|
||||
Perspektifleri entegre et ve optimizasyon için iterate et:
|
||||
|
||||
1. **Consensus tanımla** (güçlü sinyal)
|
||||
2. **Divergence tanımla** (değerlendirme gerektirir)
|
||||
3. **Tamamlayıcı güçlü yönler**: Backend logic Codex'i takip eder, Frontend design Gemini'yi takip eder
|
||||
4. **Mantıksal akıl yürütme**: Çözümlerdeki mantıksal boşlukları elimine et
|
||||
|
||||
#### 2.3 (İsteğe Bağlı ama Önerilen) Dual-Model Plan Taslağı
|
||||
|
||||
Claude'un sentezlenmiş planındaki eksiklik riskini azaltmak için, her iki modelin de "plan taslakları" çıktılamasını parallel yaptır (yine **dosya değiştirmesine izin verilmez**):
|
||||
|
||||
1. **Codex Plan Draft** (Backend otoritesi):
|
||||
- ROLE_FILE: `~/.claude/.ccg/prompts/codex/architect.md`
|
||||
- OUTPUT: Adım adım plan + pseudo-code (odak: data flow/edge cases/error handling/test strategy)
|
||||
|
||||
2. **Gemini Plan Draft** (Frontend otoritesi):
|
||||
- ROLE_FILE: `~/.claude/.ccg/prompts/gemini/architect.md`
|
||||
- OUTPUT: Adım adım plan + pseudo-code (odak: information architecture/interaction/accessibility/visual consistency)
|
||||
|
||||
`TaskOutput` ile her iki modelin tam sonuçlarını bekle, önerilerindeki anahtar farkları kaydet.
|
||||
|
||||
#### 2.4 Implementation Planı Oluştur (Claude Final Version)
|
||||
|
||||
Her iki analizi sentezle, **Adım Adım Implementation Planı** oluştur:
|
||||
|
||||
```markdown
|
||||
## Implementation Plan: <Task Name>
|
||||
|
||||
### Task Type
|
||||
- [ ] Frontend (→ Gemini)
|
||||
- [ ] Backend (→ Codex)
|
||||
- [ ] Fullstack (→ Parallel)
|
||||
|
||||
### Technical Solution
|
||||
<Codex + Gemini analizinden sentezlenmiş optimal çözüm>
|
||||
|
||||
### Implementation Steps
|
||||
1. <Step 1> - Beklenen teslim edilen
|
||||
2. <Step 2> - Beklenen teslim edilen
|
||||
...
|
||||
|
||||
### Key Files
|
||||
| File | Operation | Description |
|
||||
|------|-----------|-------------|
|
||||
| path/to/file.ts:L10-L50 | Modify | Description |
|
||||
|
||||
### Risks and Mitigation
|
||||
| Risk | Mitigation |
|
||||
|------|------------|
|
||||
|
||||
### SESSION_ID (for /ccg:execute use)
|
||||
- CODEX_SESSION: <session_id>
|
||||
- GEMINI_SESSION: <session_id>
|
||||
```
|
||||
|
||||
### Phase 2 End: Plan Teslimi (Execution Değil)
|
||||
|
||||
**`/ccg:plan` sorumlulukları burada biter, MUTLAKA şu aksiyonları çalıştır**:
|
||||
|
||||
1. Tam implementation planını kullanıcıya sun (pseudo-code dahil)
|
||||
2. Planı `.claude/plan/<feature-name>.md`'ye kaydet (requirement'tan feature adını çıkar, örn., `user-auth`, `payment-module`)
|
||||
3. **Kalın metinle** prompt çıktıla (MUTLAKA gerçek kaydedilen dosya yolunu kullan):
|
||||
|
||||
---
|
||||
**Plan oluşturuldu ve `.claude/plan/actual-feature-name.md` dosyasına kaydedildi**
|
||||
|
||||
**Lütfen yukarıdaki planı inceleyin. Şunları yapabilirsiniz:**
|
||||
- **Planı değiştir**: Neyin ayarlanması gerektiğini söyleyin, planı güncelleyeceğim
|
||||
- **Planı çalıştır**: Aşağıdaki komutu yeni bir oturuma kopyalayın
|
||||
|
||||
```
|
||||
/ccg:execute .claude/plan/actual-feature-name.md
|
||||
```
|
||||
---
|
||||
|
||||
**NOT**: Yukarıdaki `actual-feature-name.md` gerçek kaydedilen dosya adıyla değiştirilmelidir!
|
||||
|
||||
4. **Mevcut yanıtı hemen sonlandır** (Burada dur. Daha fazla tool çağrısı yok.)
|
||||
|
||||
**KESINLIKLE YASAK**:
|
||||
- Kullanıcıya "Y/N" sor sonra otomatik çalıştır (execution `/ccg:execute`'un sorumluluğudur)
|
||||
- Production koduna herhangi bir yazma operasyonu
|
||||
- `/ccg:execute`'u veya herhangi bir implementation aksiyonunu otomatik çağır
|
||||
- Kullanıcı açıkça değişiklik talep etmediğinde model çağrılarını tetiklemeye devam et
|
||||
|
||||
---
|
||||
|
||||
## Plan Kaydetme
|
||||
|
||||
Planlama tamamlandıktan sonra, planı şuraya kaydet:
|
||||
|
||||
- **İlk planlama**: `.claude/plan/<feature-name>.md`
|
||||
- **İterasyon versiyonları**: `.claude/plan/<feature-name>-v2.md`, `.claude/plan/<feature-name>-v3.md`...
|
||||
|
||||
Plan dosyası yazma, planı kullanıcıya sunmadan önce tamamlanmalı.
|
||||
|
||||
---
|
||||
|
||||
## Plan Değişiklik Akışı
|
||||
|
||||
Kullanıcı plan değişikliği talep ederse:
|
||||
|
||||
1. Kullanıcı geri bildirimine göre plan içeriğini ayarla
|
||||
2. `.claude/plan/<feature-name>.md` dosyasını güncelle
|
||||
3. Değiştirilmiş planı yeniden sun
|
||||
4. Kullanıcıyı tekrar gözden geçirmeye veya çalıştırmaya davet et
|
||||
|
||||
---
|
||||
|
||||
## Sonraki Adımlar
|
||||
|
||||
Kullanıcı onayladıktan sonra, **manuel** olarak çalıştır:
|
||||
|
||||
```bash
|
||||
/ccg:execute .claude/plan/<feature-name>.md
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Ana Kurallar
|
||||
|
||||
1. **Sadece plan, implementation yok** – Bu komut hiçbir kod değişikliği çalıştırmaz
|
||||
2. **Y/N prompt'ları yok** – Sadece planı sun, kullanıcının sonraki adımlara karar vermesine izin ver
|
||||
3. **Güven Kuralları** – Backend Codex'i takip eder, Frontend Gemini'yi takip eder
|
||||
4. Harici modellerin **sıfır dosya sistemi yazma erişimi**
|
||||
5. **SESSION_ID Devri** – Plan sonunda `CODEX_SESSION` / `GEMINI_SESSION` içermeli (`/ccg:execute resume <SESSION_ID>` kullanımı için)
|
||||
191
docs/tr/commands/multi-workflow.md
Normal file
191
docs/tr/commands/multi-workflow.md
Normal file
@@ -0,0 +1,191 @@
|
||||
# Workflow - Multi-Model İşbirlikçi Geliştirme
|
||||
|
||||
Multi-model işbirlikçi geliştirme iş akışı (Research → Ideation → Plan → Execute → Optimize → Review), akıllı yönlendirme ile: Frontend → Gemini, Backend → Codex.
|
||||
|
||||
Kalite kontrol noktaları, MCP servisleri ve multi-model işbirliği ile yapılandırılmış geliştirme iş akışı.
|
||||
|
||||
## Kullanım
|
||||
|
||||
```bash
|
||||
/workflow <task açıklaması>
|
||||
```
|
||||
|
||||
## Context
|
||||
|
||||
- Geliştirilecek görev: $ARGUMENTS
|
||||
- Kalite kontrol noktalarıyla 6 fazlı yapılandırılmış iş akışı
|
||||
- Multi-model işbirliği: Codex (backend) + Gemini (frontend) + Claude (orkestrasyon)
|
||||
- MCP servis entegrasyonu (ace-tool, isteğe bağlı) gelişmiş yetenekler için
|
||||
|
||||
## Rolünüz
|
||||
|
||||
**Orkestratör**sünüz, multi-model işbirlikçi sistemi koordine ediyorsunuz (Research → Ideation → Plan → Execute → Optimize → Review). Deneyimli geliştiriciler için kısa ve profesyonel iletişim kurun.
|
||||
|
||||
**İşbirlikçi Modeller**:
|
||||
- **ace-tool MCP** (isteğe bağlı) – Code retrieval + Prompt enhancement
|
||||
- **Codex** – Backend logic, algoritmalar, debugging (**Backend otoritesi, güvenilir**)
|
||||
- **Gemini** – Frontend UI/UX, görsel tasarım (**Frontend uzmanı, backend görüşleri sadece referans için**)
|
||||
- **Claude (self)** – Orkestrasyon, planlama, execution, teslimat
|
||||
|
||||
---
|
||||
|
||||
## Multi-Model Çağrı Spesifikasyonu
|
||||
|
||||
**Çağrı sözdizimi** (parallel: `run_in_background: true`, sequential: `false`):
|
||||
|
||||
```
|
||||
# Yeni session çağrısı
|
||||
Bash({
|
||||
command: "~/.claude/bin/codeagent-wrapper {{LITE_MODE_FLAG}}--backend <codex|gemini> {{GEMINI_MODEL_FLAG}}- \"$PWD\" <<'EOF'
|
||||
ROLE_FILE: <role prompt path>
|
||||
<TASK>
|
||||
Requirement: <enhanced requirement (veya enhance edilmediyse $ARGUMENTS)>
|
||||
Context: <önceki fazlardan proje context'i ve analiz>
|
||||
</TASK>
|
||||
OUTPUT: Expected output format
|
||||
EOF",
|
||||
run_in_background: true,
|
||||
timeout: 3600000,
|
||||
description: "Brief description"
|
||||
})
|
||||
|
||||
# Session devam ettirme çağrısı
|
||||
Bash({
|
||||
command: "~/.claude/bin/codeagent-wrapper {{LITE_MODE_FLAG}}--backend <codex|gemini> {{GEMINI_MODEL_FLAG}}resume <SESSION_ID> - \"$PWD\" <<'EOF'
|
||||
ROLE_FILE: <role prompt path>
|
||||
<TASK>
|
||||
Requirement: <enhanced requirement (veya enhance edilmediyse $ARGUMENTS)>
|
||||
Context: <önceki fazlardan proje context'i ve analiz>
|
||||
</TASK>
|
||||
OUTPUT: Expected output format
|
||||
EOF",
|
||||
run_in_background: true,
|
||||
timeout: 3600000,
|
||||
description: "Brief description"
|
||||
})
|
||||
```
|
||||
|
||||
**Model Parametre Notları**:
|
||||
- `{{GEMINI_MODEL_FLAG}}`: `--backend gemini` kullanırken, `--gemini-model gemini-3-pro-preview` ile değiştir (trailing space not edin); codex için boş string kullan
|
||||
|
||||
**Role Prompts**:
|
||||
|
||||
| Phase | Codex | Gemini |
|
||||
|-------|-------|--------|
|
||||
| Analysis | `~/.claude/.ccg/prompts/codex/analyzer.md` | `~/.claude/.ccg/prompts/gemini/analyzer.md` |
|
||||
| Planning | `~/.claude/.ccg/prompts/codex/architect.md` | `~/.claude/.ccg/prompts/gemini/architect.md` |
|
||||
| Review | `~/.claude/.ccg/prompts/codex/reviewer.md` | `~/.claude/.ccg/prompts/gemini/reviewer.md` |
|
||||
|
||||
**Session Reuse**: Her çağrı `SESSION_ID: xxx` döndürür, sonraki fazlar için `resume xxx` subcommand kullan (not: `resume`, `--resume` değil).
|
||||
|
||||
**Parallel Çağrılar**: Başlatmak için `run_in_background: true` kullan, sonuçları `TaskOutput` ile bekle. **Bir sonraki faza geçmeden önce tüm modellerin dönmesini MUTLAKA bekle**.
|
||||
|
||||
**Background Task'leri Bekle** (max timeout 600000ms = 10 dakika kullan):
|
||||
|
||||
```
|
||||
TaskOutput({ task_id: "<task_id>", block: true, timeout: 600000 })
|
||||
```
|
||||
|
||||
**ÖNEMLİ**:
|
||||
- `timeout: 600000` belirtilmeli, aksi takdirde varsayılan 30 saniye erken timeout'a neden olur.
|
||||
- 10 dakika sonra hala tamamlanmamışsa, `TaskOutput` ile polling'e devam et, **ASLA process'i öldürme**.
|
||||
- Bekleme timeout nedeniyle atlanırsa, **MUTLAKA `AskUserQuestion` çağırarak kullanıcıya beklemeye devam etmek veya task'i öldürmek isteyip istemediğini sor. Asla doğrudan öldürme.**
|
||||
|
||||
---
|
||||
|
||||
## İletişim Yönergeleri
|
||||
|
||||
1. Yanıtlara mode etiketi `[Mode: X]` ile başla, ilk `[Mode: Research]`.
|
||||
2. Katı sıra takip et: `Research → Ideation → Plan → Execute → Optimize → Review`.
|
||||
3. Her faz tamamlandıktan sonra kullanıcı onayı iste.
|
||||
4. Skor < 7 veya kullanıcı onaylamadığında zorla durdur.
|
||||
5. Gerektiğinde kullanıcı etkileşimi için `AskUserQuestion` tool kullan (örn., onay/seçim/approval).
|
||||
|
||||
## Harici Orkestrasyon Ne Zaman Kullanılır
|
||||
|
||||
İş paralel worker'lar arasında bölünmesi gerektiğinde harici tmux/worktree orkestrasyonu kullan; bu worker'ların izole git state'i, bağımsız terminalleri veya ayrı build/test çalıştırması gerekir. Hafif analiz, planlama veya review için in-process subagent'ları kullan; burada ana session tek yazar olarak kalır.
|
||||
|
||||
```bash
|
||||
node scripts/orchestrate-worktrees.js .claude/plan/workflow-e2e-test.json --execute
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Execution Workflow
|
||||
|
||||
**Task Açıklaması**: $ARGUMENTS
|
||||
|
||||
### Phase 1: Research & Analysis
|
||||
|
||||
`[Mode: Research]` - Requirement'ları anla ve context topla:
|
||||
|
||||
1. **Prompt Enhancement** (ace-tool MCP mevcutsa): `mcp__ace-tool__enhance_prompt` çağır, **orijinal $ARGUMENTS'ı tüm sonraki Codex/Gemini çağrıları için enhanced sonuçla değiştir**. Mevcut değilse, `$ARGUMENTS`'ı olduğu gibi kullan.
|
||||
2. **Context Retrieval** (ace-tool MCP mevcutsa): `mcp__ace-tool__search_context` çağır. Mevcut değilse, built-in tool'ları kullan: dosya keşfi için `Glob`, sembol araması için `Grep`, context toplama için `Read`, daha derin keşif için `Task` (Explore agent).
|
||||
3. **Requirement Tamamlılık Skoru** (0-10):
|
||||
- Hedef netliği (0-3), Beklenen sonuç (0-3), Kapsam sınırları (0-2), Kısıtlamalar (0-2)
|
||||
- ≥7: Devam et | <7: Dur, açıklayıcı sorular sor
|
||||
|
||||
### Phase 2: Solution Ideation
|
||||
|
||||
`[Mode: Ideation]` - Multi-model parallel analiz:
|
||||
|
||||
**Parallel Çağrılar** (`run_in_background: true`):
|
||||
- Codex: Analyzer prompt kullan, teknik fizibilite, çözümler, riskler çıktıla
|
||||
- Gemini: Analyzer prompt kullan, UI fizibilite, çözümler, UX değerlendirmesi çıktıla
|
||||
|
||||
`TaskOutput` ile sonuçları bekle. **SESSION_ID'yi kaydet** (`CODEX_SESSION` ve `GEMINI_SESSION`).
|
||||
|
||||
**Yukarıdaki `Multi-Model Çağrı Spesifikasyonu`'ndaki `ÖNEMLİ` talimatları takip et**
|
||||
|
||||
Her iki analizi sentezle, çözüm karşılaştırması çıktıla (en az 2 seçenek), kullanıcı seçimini bekle.
|
||||
|
||||
### Phase 3: Detailed Planning
|
||||
|
||||
`[Mode: Plan]` - Multi-model işbirlikçi planlama:
|
||||
|
||||
**Parallel Çağrılar** (`resume <SESSION_ID>` ile session devam ettir):
|
||||
- Codex: Architect prompt + `resume $CODEX_SESSION` kullan, backend mimarisi çıktıla
|
||||
- Gemini: Architect prompt + `resume $GEMINI_SESSION` kullan, frontend mimarisi çıktıla
|
||||
|
||||
`TaskOutput` ile sonuçları bekle.
|
||||
|
||||
**Yukarıdaki `Multi-Model Çağrı Spesifikasyonu`'ndaki `ÖNEMLİ` talimatları takip et**
|
||||
|
||||
**Claude Sentezi**: Codex backend planı + Gemini frontend planını benimsle, kullanıcı onayından sonra `.claude/plan/task-name.md`'ye kaydet.
|
||||
|
||||
### Phase 4: Implementation
|
||||
|
||||
`[Mode: Execute]` - Kod geliştirme:
|
||||
|
||||
- Onaylanan planı kesinlikle takip et
|
||||
- Mevcut proje kod standartlarını takip et
|
||||
- Önemli kilometre taşlarında geri bildirim iste
|
||||
|
||||
### Phase 5: Code Optimization
|
||||
|
||||
`[Mode: Optimize]` - Multi-model parallel review:
|
||||
|
||||
**Parallel Çağrılar**:
|
||||
- Codex: Reviewer prompt kullan, güvenlik, performans, hata işleme üzerine odaklan
|
||||
- Gemini: Reviewer prompt kullan, accessibility, tasarım tutarlılığı üzerine odaklan
|
||||
|
||||
`TaskOutput` ile sonuçları bekle. Review geri bildirimlerini entegre et, kullanıcı onayından sonra optimizasyonu çalıştır.
|
||||
|
||||
**Yukarıdaki `Multi-Model Çağrı Spesifikasyonu`'ndaki `ÖNEMLİ` talimatları takip et**
|
||||
|
||||
### Phase 6: Quality Review
|
||||
|
||||
`[Mode: Review]` - Nihai değerlendirme:
|
||||
|
||||
- Plana karşı tamamlılığı kontrol et
|
||||
- Fonksiyonaliteyi doğrulamak için test'leri çalıştır
|
||||
- Sorunları ve önerileri raporla
|
||||
- Nihai kullanıcı onayı iste
|
||||
|
||||
---
|
||||
|
||||
## Ana Kurallar
|
||||
|
||||
1. Faz sırası atlanamaz (kullanıcı açıkça talimat vermedikçe)
|
||||
2. Harici modellerin **sıfır dosya sistemi yazma erişimi**, tüm değişiklikler Claude tarafından
|
||||
3. Skor < 7 veya kullanıcı onaylamadığında **zorla durdur**
|
||||
231
docs/tr/commands/orchestrate.md
Normal file
231
docs/tr/commands/orchestrate.md
Normal file
@@ -0,0 +1,231 @@
|
||||
---
|
||||
description: Multi-agent iş akışları için sıralı ve tmux/worktree orkestrasyon rehberi.
|
||||
---
|
||||
|
||||
# Orchestrate Komutu
|
||||
|
||||
Karmaşık görevler için sıralı agent iş akışı.
|
||||
|
||||
## Kullanım
|
||||
|
||||
`/orchestrate [workflow-type] [task-description]`
|
||||
|
||||
## Workflow Tipleri
|
||||
|
||||
### feature
|
||||
Tam özellik implementasyon iş akışı:
|
||||
```
|
||||
planner -> tdd-guide -> code-reviewer -> security-reviewer
|
||||
```
|
||||
|
||||
### bugfix
|
||||
Bug araştırma ve düzeltme iş akışı:
|
||||
```
|
||||
planner -> tdd-guide -> code-reviewer
|
||||
```
|
||||
|
||||
### refactor
|
||||
Güvenli refactoring iş akışı:
|
||||
```
|
||||
architect -> code-reviewer -> tdd-guide
|
||||
```
|
||||
|
||||
### security
|
||||
Güvenlik odaklı review:
|
||||
```
|
||||
security-reviewer -> code-reviewer -> architect
|
||||
```
|
||||
|
||||
## Execution Pattern
|
||||
|
||||
İş akışındaki her agent için:
|
||||
|
||||
1. **Agent'ı çağır** önceki agent'tan gelen context ile
|
||||
2. **Çıktıyı topla** yapılandırılmış handoff dokümanı olarak
|
||||
3. **Sonraki agent'a geçir** zincirde
|
||||
4. **Sonuçları topla** nihai rapora
|
||||
|
||||
## Handoff Doküman Formatı
|
||||
|
||||
Agent'lar arasında, handoff dokümanı oluştur:
|
||||
|
||||
```markdown
|
||||
## HANDOFF: [previous-agent] -> [next-agent]
|
||||
|
||||
### Context
|
||||
[Yapılanların özeti]
|
||||
|
||||
### Findings
|
||||
[Anahtar keşifler veya kararlar]
|
||||
|
||||
### Files Modified
|
||||
[Dokunulan dosyaların listesi]
|
||||
|
||||
### Open Questions
|
||||
[Sonraki agent için çözülmemiş öğeler]
|
||||
|
||||
### Recommendations
|
||||
[Önerilen sonraki adımlar]
|
||||
```
|
||||
|
||||
## Örnek: Feature Workflow
|
||||
|
||||
```
|
||||
/orchestrate feature "Add user authentication"
|
||||
```
|
||||
|
||||
Çalıştırır:
|
||||
|
||||
1. **Planner Agent**
|
||||
- Requirement'ları analiz eder
|
||||
- Implementation planı oluşturur
|
||||
- Bağımlılıkları tanımlar
|
||||
- Çıktı: `HANDOFF: planner -> tdd-guide`
|
||||
|
||||
2. **TDD Guide Agent**
|
||||
- Planner handoff'unu okur
|
||||
- Önce test'leri yazar
|
||||
- Test'leri geçirmek için implement eder
|
||||
- Çıktı: `HANDOFF: tdd-guide -> code-reviewer`
|
||||
|
||||
3. **Code Reviewer Agent**
|
||||
- Implementation'ı gözden geçirir
|
||||
- Sorunları kontrol eder
|
||||
- İyileştirmeler önerir
|
||||
- Çıktı: `HANDOFF: code-reviewer -> security-reviewer`
|
||||
|
||||
4. **Security Reviewer Agent**
|
||||
- Güvenlik denetimi
|
||||
- Güvenlik açığı kontrolü
|
||||
- Nihai onay
|
||||
- Çıktı: Final Report
|
||||
|
||||
## Nihai Rapor Formatı
|
||||
|
||||
```
|
||||
ORCHESTRATION REPORT
|
||||
====================
|
||||
Workflow: feature
|
||||
Task: Add user authentication
|
||||
Agents: planner -> tdd-guide -> code-reviewer -> security-reviewer
|
||||
|
||||
SUMMARY
|
||||
-------
|
||||
[Bir paragraf özet]
|
||||
|
||||
AGENT OUTPUTS
|
||||
-------------
|
||||
Planner: [özet]
|
||||
TDD Guide: [özet]
|
||||
Code Reviewer: [özet]
|
||||
Security Reviewer: [özet]
|
||||
|
||||
FILES CHANGED
|
||||
-------------
|
||||
[Değiştirilen tüm dosyaların listesi]
|
||||
|
||||
TEST RESULTS
|
||||
------------
|
||||
[Test geçti/başarısız özeti]
|
||||
|
||||
SECURITY STATUS
|
||||
---------------
|
||||
[Güvenlik bulguları]
|
||||
|
||||
RECOMMENDATION
|
||||
--------------
|
||||
[SHIP / NEEDS WORK / BLOCKED]
|
||||
```
|
||||
|
||||
## Parallel Execution
|
||||
|
||||
Bağımsız kontroller için, agent'ları parallel çalıştır:
|
||||
|
||||
```markdown
|
||||
### Parallel Phase
|
||||
Eş zamanlı çalıştır:
|
||||
- code-reviewer (kalite)
|
||||
- security-reviewer (güvenlik)
|
||||
- architect (tasarım)
|
||||
|
||||
### Merge Results
|
||||
Çıktıları tek rapora birleştir
|
||||
```
|
||||
|
||||
Ayrı git worktree'leri olan harici tmux-pane worker'ları için, `node scripts/orchestrate-worktrees.js plan.json --execute` kullan. Built-in orkestrasyon pattern'i in-process kalır; helper uzun süren veya cross-harness session'lar için.
|
||||
|
||||
Worker'ların ana checkout'tan kirli veya izlenmeyen yerel dosyaları görmesi gerektiğinde, plan dosyasına `seedPaths` ekle. ECC sadece seçilen bu yolları `git worktree add`'den sonra her worker worktree'sine overlay eder; bu branch'ı izole tutarken devam eden yerel script'leri, planları veya dokümanları gösterir.
|
||||
|
||||
```json
|
||||
{
|
||||
"sessionName": "workflow-e2e",
|
||||
"seedPaths": [
|
||||
"scripts/orchestrate-worktrees.js",
|
||||
"scripts/lib/tmux-worktree-orchestrator.js",
|
||||
".claude/plan/workflow-e2e-test.json"
|
||||
],
|
||||
"workers": [
|
||||
{ "name": "docs", "task": "Orkestrasyon dokümanlarını güncelle." }
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
Canlı bir tmux/worktree session için kontrol düzlemi snapshot'ı dışa aktarmak için şunu çalıştır:
|
||||
|
||||
```bash
|
||||
node scripts/orchestration-status.js .claude/plan/workflow-visual-proof.json
|
||||
```
|
||||
|
||||
Snapshot session aktivitesi, tmux pane metadata'sı, worker state'leri, hedefleri, seed overlay'leri ve son handoff özetlerini JSON formatında içerir.
|
||||
|
||||
## Operatör Command-Center Handoff
|
||||
|
||||
İş akışı birden fazla session, worktree veya tmux pane'e yayıldığında, nihai handoff'a bir kontrol düzlemi bloğu ekle:
|
||||
|
||||
```markdown
|
||||
CONTROL PLANE
|
||||
-------------
|
||||
Sessions:
|
||||
- aktif session ID veya alias
|
||||
- her aktif worker için branch + worktree yolu
|
||||
- uygulanabilir durumlarda tmux pane veya detached session adı
|
||||
|
||||
Diffs:
|
||||
- git status özeti
|
||||
- dokunulan dosyalar için git diff --stat
|
||||
- merge/çakışma risk notları
|
||||
|
||||
Approvals:
|
||||
- bekleyen kullanıcı onayları
|
||||
- onay bekleyen bloke adımlar
|
||||
|
||||
Telemetry:
|
||||
- son aktivite timestamp'i veya idle sinyali
|
||||
- tahmini token veya cost drift
|
||||
- hook'lar veya reviewer'lar tarafından bildirilen policy olayları
|
||||
```
|
||||
|
||||
Bu planner, implementer, reviewer ve loop worker'larını operatör yüzeyinden anlaşılır tutar.
|
||||
|
||||
## Argümanlar
|
||||
|
||||
$ARGUMENTS:
|
||||
- `feature <description>` - Tam özellik iş akışı
|
||||
- `bugfix <description>` - Bug düzeltme iş akışı
|
||||
- `refactor <description>` - Refactoring iş akışı
|
||||
- `security <description>` - Güvenlik review iş akışı
|
||||
- `custom <agents> <description>` - Özel agent dizisi
|
||||
|
||||
## Özel Workflow Örneği
|
||||
|
||||
```
|
||||
/orchestrate custom "architect,tdd-guide,code-reviewer" "Caching katmanını yeniden tasarla"
|
||||
```
|
||||
|
||||
## İpuçları
|
||||
|
||||
1. **Karmaşık özellikler için planner ile başla**
|
||||
2. **Merge'den önce her zaman code-reviewer dahil et**
|
||||
3. **Auth/ödeme/PII için security-reviewer kullan**
|
||||
4. **Handoff'ları kısa tut** - sonraki agent'ın ihtiyaç duyduğu şeye odaklan
|
||||
5. **Gerekirse agent'lar arasında doğrulama çalıştır**
|
||||
115
docs/tr/commands/plan.md
Normal file
115
docs/tr/commands/plan.md
Normal file
@@ -0,0 +1,115 @@
|
||||
---
|
||||
description: Gereksinimleri yeniden ifade et, riskleri değerlendir ve adım adım uygulama planı oluştur. Herhangi bir koda dokunmadan önce kullanıcı ONAYINI BEKLE.
|
||||
---
|
||||
|
||||
# Plan Komutu
|
||||
|
||||
Bu komut, herhangi bir kod yazmadan önce kapsamlı bir uygulama planı oluşturmak için **planner** agent'ını çağırır.
|
||||
|
||||
## Bu Komut Ne Yapar
|
||||
|
||||
1. **Gereksinimleri Yeniden İfade Et** - Neyin inşa edilmesi gerektiğini netleştir
|
||||
2. **Riskleri Tanımla** - Potansiyel sorunları ve engelleri ortaya çıkar
|
||||
3. **Adım Planı Oluştur** - Uygulamayı fazlara ayır
|
||||
4. **Onay Bekle** - İlerlemeden önce kullanıcı onayı alınmalıdır
|
||||
|
||||
## Ne Zaman Kullanılır
|
||||
|
||||
`/plan` komutunu şu durumlarda kullanın:
|
||||
- Yeni bir özelliğe başlarken
|
||||
- Önemli mimari değişiklikler yaparken
|
||||
- Karmaşık refactoring üzerinde çalışırken
|
||||
- Birden fazla dosya/component etkilenecekken
|
||||
- Gereksinimler belirsiz veya muğlak olduğunda
|
||||
|
||||
## Nasıl Çalışır
|
||||
|
||||
Planner agent'ı şunları yapacaktır:
|
||||
|
||||
1. İsteği **analiz edecek** ve gereksinimleri net şekilde yeniden ifade edecek
|
||||
2. Belirli, uygulanabilir adımlarla **fazlara ayıracak**
|
||||
3. Componentler arası **bağımlılıkları tanımlayacak**
|
||||
4. **Riskleri değerlendirecek** ve potansiyel engelleri belirleyecek
|
||||
5. **Karmaşıklığı tahmin edecek** (Yüksek/Orta/Düşük)
|
||||
6. **Planı sunacak** ve açık onayınızı bekleyecek
|
||||
|
||||
## Örnek Kullanım
|
||||
|
||||
```
|
||||
Kullanıcı: /plan Piyasalar çözüldüğünde gerçek zamanlı bildirimler eklemeye ihtiyacım var
|
||||
|
||||
Agent (planner):
|
||||
# Uygulama Planı: Gerçek Zamanlı Piyasa Çözüm Bildirimleri
|
||||
|
||||
## Gereksinim Yeniden İfadesi
|
||||
- Kullanıcılar takip ettikleri piyasalar çözüldüğünde bildirim alsın
|
||||
- Birden fazla bildirim kanalını destekle (uygulama içi, e-posta, webhook)
|
||||
- Bildirimlerin güvenilir bir şekilde iletilmesini sağla
|
||||
- Piyasa sonucunu ve kullanıcının pozisyon sonucunu içer
|
||||
|
||||
## Uygulama Fazları
|
||||
|
||||
### Faz 1: Database Şeması
|
||||
- Kolonlarla bildirimler tablosu ekle: id, user_id, market_id, type, status, created_at
|
||||
- Kanal tercihleri için user_notification_preferences tablosu ekle
|
||||
- Performans için user_id ve market_id üzerinde indexler oluştur
|
||||
|
||||
### Faz 2: Bildirim Servisi
|
||||
- lib/notifications.ts'de bildirim servisi oluştur
|
||||
- BullMQ/Redis kullanarak bildirim kuyruğu uygula
|
||||
- Başarısız teslimatlar için yeniden deneme mantığı ekle
|
||||
- Bildirim şablonları oluştur
|
||||
|
||||
### Faz 3: Entegrasyon Noktaları
|
||||
- Piyasa çözüm mantığına bağlan (durum "resolved" olduğunda)
|
||||
- Piyasada pozisyonu olan tüm kullanıcıları sorgula
|
||||
- Her kullanıcı için bildirimleri kuyruğa ekle
|
||||
|
||||
### Faz 4: Frontend Componentleri
|
||||
- Header'da NotificationBell componenti oluştur
|
||||
- NotificationList modal'ı ekle
|
||||
- Supabase subscriptions ile gerçek zamanlı güncellemeler uygula
|
||||
- Bildirim tercihleri sayfası ekle
|
||||
|
||||
## Bağımlılıklar
|
||||
- Redis (kuyruk için)
|
||||
- E-posta servisi (SendGrid/Resend)
|
||||
- Supabase real-time subscriptions
|
||||
|
||||
## Riskler
|
||||
- YÜKSEK: E-posta teslimatı (SPF/DKIM gerekli)
|
||||
- ORTA: Piyasa başına 1000+ kullanıcı ile performans
|
||||
- ORTA: Piyasalar sık çözülürse bildirim spam'i
|
||||
- DÜŞÜK: Real-time subscription yükü
|
||||
|
||||
## Tahmini Karmaşıklık: ORTA
|
||||
- Backend: 4-6 saat
|
||||
- Frontend: 3-4 saat
|
||||
- Test: 2-3 saat
|
||||
- Toplam: 9-13 saat
|
||||
|
||||
**ONAY BEKLENİYOR**: Bu planla ilerleyelim mi? (evet/hayır/değiştir)
|
||||
```
|
||||
|
||||
## Önemli Notlar
|
||||
|
||||
**KRİTİK**: Planner agent, planı "evet" veya "ilerle" veya benzeri olumlu bir yanıtla açıkça onaylayana kadar herhangi bir kod **YAZMAYACAK**.
|
||||
|
||||
Değişiklik istiyorsanız, şu şekilde yanıt verin:
|
||||
- "değiştir: [değişiklikleriniz]"
|
||||
- "farklı yaklaşım: [alternatif]"
|
||||
- "faz 2'yi atla ve önce faz 3'ü yap"
|
||||
|
||||
## Diğer Komutlarla Entegrasyon
|
||||
|
||||
Planlamadan sonra:
|
||||
- Test odaklı geliştirme ile uygulamak için `/tdd` kullanın
|
||||
- Build hataları oluşursa `/build-fix` kullanın
|
||||
- Tamamlanan uygulamayı gözden geçirmek için `/code-review` kullanın
|
||||
|
||||
## İlgili Agent'lar
|
||||
|
||||
Bu komut, ECC tarafından sağlanan `planner` agent'ını çağırır.
|
||||
|
||||
Manuel kurulumlar için, kaynak dosya şurada bulunur:
|
||||
`agents/planner.md`
|
||||
272
docs/tr/commands/pm2.md
Normal file
272
docs/tr/commands/pm2.md
Normal file
@@ -0,0 +1,272 @@
|
||||
# PM2 Init
|
||||
|
||||
Projeyi otomatik analiz et ve PM2 servis komutları oluştur.
|
||||
|
||||
**Komut**: `$ARGUMENTS`
|
||||
|
||||
---
|
||||
|
||||
## İş Akışı
|
||||
|
||||
1. PM2'yi kontrol et (yoksa `npm install -g pm2` ile yükle)
|
||||
2. Servisleri (frontend/backend/database) tanımlamak için projeyi tara
|
||||
3. Config dosyaları ve bireysel komut dosyaları oluştur
|
||||
|
||||
---
|
||||
|
||||
## Servis Tespiti
|
||||
|
||||
| Tip | Tespit | Varsayılan Port |
|
||||
|------|-----------|--------------|
|
||||
| Vite | vite.config.* | 5173 |
|
||||
| Next.js | next.config.* | 3000 |
|
||||
| Nuxt | nuxt.config.* | 3000 |
|
||||
| CRA | package.json'da react-scripts | 3000 |
|
||||
| Express/Node | server/backend/api dizini + package.json | 3000 |
|
||||
| FastAPI/Flask | requirements.txt / pyproject.toml | 8000 |
|
||||
| Go | go.mod / main.go | 8080 |
|
||||
|
||||
**Port Tespit Önceliği**: Kullanıcı belirtimi > .env > config dosyası > script argümanları > varsayılan port
|
||||
|
||||
---
|
||||
|
||||
## Oluşturulan Dosyalar
|
||||
|
||||
```
|
||||
project/
|
||||
├── ecosystem.config.cjs # PM2 config
|
||||
├── {backend}/start.cjs # Python wrapper (geçerliyse)
|
||||
└── .claude/
|
||||
├── commands/
|
||||
│ ├── pm2-all.md # Hepsini başlat + monit
|
||||
│ ├── pm2-all-stop.md # Hepsini durdur
|
||||
│ ├── pm2-all-restart.md # Hepsini yeniden başlat
|
||||
│ ├── pm2-{port}.md # Tekli başlat + logs
|
||||
│ ├── pm2-{port}-stop.md # Tekli durdur
|
||||
│ ├── pm2-{port}-restart.md # Tekli yeniden başlat
|
||||
│ ├── pm2-logs.md # Tüm logları göster
|
||||
│ └── pm2-status.md # Durumu göster
|
||||
└── scripts/
|
||||
├── pm2-logs-{port}.ps1 # Tekli servis logları
|
||||
└── pm2-monit.ps1 # PM2 monitor
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Windows Konfigürasyonu (ÖNEMLİ)
|
||||
|
||||
### ecosystem.config.cjs
|
||||
|
||||
**`.cjs` uzantısı kullanmalı**
|
||||
|
||||
```javascript
|
||||
module.exports = {
|
||||
apps: [
|
||||
// Node.js (Vite/Next/Nuxt)
|
||||
{
|
||||
name: 'project-3000',
|
||||
cwd: './packages/web',
|
||||
script: 'node_modules/vite/bin/vite.js',
|
||||
args: '--port 3000',
|
||||
interpreter: 'C:/Program Files/nodejs/node.exe',
|
||||
env: { NODE_ENV: 'development' }
|
||||
},
|
||||
// Python
|
||||
{
|
||||
name: 'project-8000',
|
||||
cwd: './backend',
|
||||
script: 'start.cjs',
|
||||
interpreter: 'C:/Program Files/nodejs/node.exe',
|
||||
env: { PYTHONUNBUFFERED: '1' }
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
**Framework script yolları:**
|
||||
|
||||
| Framework | script | args |
|
||||
|-----------|--------|------|
|
||||
| Vite | `node_modules/vite/bin/vite.js` | `--port {port}` |
|
||||
| Next.js | `node_modules/next/dist/bin/next` | `dev -p {port}` |
|
||||
| Nuxt | `node_modules/nuxt/bin/nuxt.mjs` | `dev --port {port}` |
|
||||
| Express | `src/index.js` veya `server.js` | - |
|
||||
|
||||
### Python Wrapper Script (start.cjs)
|
||||
|
||||
```javascript
|
||||
const { spawn } = require('child_process');
|
||||
const proc = spawn('python', ['-m', 'uvicorn', 'app.main:app', '--host', '0.0.0.0', '--port', '8000', '--reload'], {
|
||||
cwd: __dirname, stdio: 'inherit', windowsHide: true
|
||||
});
|
||||
proc.on('close', (code) => process.exit(code));
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Komut Dosyası Şablonları (Minimal İçerik)
|
||||
|
||||
### pm2-all.md (Hepsini başlat + monit)
|
||||
````markdown
|
||||
Tüm servisleri başlat ve PM2 monitör aç.
|
||||
```bash
|
||||
cd "{PROJECT_ROOT}" && pm2 start ecosystem.config.cjs && start wt.exe -d "{PROJECT_ROOT}" pwsh -NoExit -c "pm2 monit"
|
||||
```
|
||||
````
|
||||
|
||||
### pm2-all-stop.md
|
||||
````markdown
|
||||
Tüm servisleri durdur.
|
||||
```bash
|
||||
cd "{PROJECT_ROOT}" && pm2 stop all
|
||||
```
|
||||
````
|
||||
|
||||
### pm2-all-restart.md
|
||||
````markdown
|
||||
Tüm servisleri yeniden başlat.
|
||||
```bash
|
||||
cd "{PROJECT_ROOT}" && pm2 restart all
|
||||
```
|
||||
````
|
||||
|
||||
### pm2-{port}.md (Tekli başlat + logs)
|
||||
````markdown
|
||||
{name} ({port}) başlat ve logları aç.
|
||||
```bash
|
||||
cd "{PROJECT_ROOT}" && pm2 start ecosystem.config.cjs --only {name} && start wt.exe -d "{PROJECT_ROOT}" pwsh -NoExit -c "pm2 logs {name}"
|
||||
```
|
||||
````
|
||||
|
||||
### pm2-{port}-stop.md
|
||||
````markdown
|
||||
{name} ({port}) durdur.
|
||||
```bash
|
||||
cd "{PROJECT_ROOT}" && pm2 stop {name}
|
||||
```
|
||||
````
|
||||
|
||||
### pm2-{port}-restart.md
|
||||
````markdown
|
||||
{name} ({port}) yeniden başlat.
|
||||
```bash
|
||||
cd "{PROJECT_ROOT}" && pm2 restart {name}
|
||||
```
|
||||
````
|
||||
|
||||
### pm2-logs.md
|
||||
````markdown
|
||||
Tüm PM2 loglarını göster.
|
||||
```bash
|
||||
cd "{PROJECT_ROOT}" && pm2 logs
|
||||
```
|
||||
````
|
||||
|
||||
### pm2-status.md
|
||||
````markdown
|
||||
PM2 durumunu göster.
|
||||
```bash
|
||||
cd "{PROJECT_ROOT}" && pm2 status
|
||||
```
|
||||
````
|
||||
|
||||
### PowerShell Scripts (pm2-logs-{port}.ps1)
|
||||
```powershell
|
||||
Set-Location "{PROJECT_ROOT}"
|
||||
pm2 logs {name}
|
||||
```
|
||||
|
||||
### PowerShell Scripts (pm2-monit.ps1)
|
||||
```powershell
|
||||
Set-Location "{PROJECT_ROOT}"
|
||||
pm2 monit
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Ana Kurallar
|
||||
|
||||
1. **Config dosyası**: `ecosystem.config.cjs` (.js değil)
|
||||
2. **Node.js**: Bin yolunu doğrudan belirt + interpreter
|
||||
3. **Python**: Node.js wrapper script + `windowsHide: true`
|
||||
4. **Yeni pencere aç**: `start wt.exe -d "{path}" pwsh -NoExit -c "command"`
|
||||
5. **Minimal içerik**: Her komut dosyası sadece 1-2 satır açıklama + bash bloğu
|
||||
6. **Doğrudan çalıştırma**: AI ayrıştırması gerekmez, sadece bash komutunu çalıştır
|
||||
|
||||
---
|
||||
|
||||
## Çalıştır
|
||||
|
||||
`$ARGUMENTS`'a göre init'i çalıştır:
|
||||
|
||||
1. Servisleri taramak için projeyi tara
|
||||
2. `ecosystem.config.cjs` oluştur
|
||||
3. Python servisleri için `{backend}/start.cjs` oluştur (geçerliyse)
|
||||
4. `.claude/commands/` dizininde komut dosyaları oluştur
|
||||
5. `.claude/scripts/` dizininde script dosyaları oluştur
|
||||
6. **Proje CLAUDE.md'yi PM2 bilgisiyle güncelle** (aşağıya bakın)
|
||||
7. **Terminal komutlarıyla tamamlama özetini göster**
|
||||
|
||||
---
|
||||
|
||||
## Post-Init: CLAUDE.md'yi Güncelle
|
||||
|
||||
Dosyalar oluşturulduktan sonra, projenin `CLAUDE.md` dosyasına PM2 bölümünü ekle (yoksa oluştur):
|
||||
|
||||
````markdown
|
||||
## PM2 Services
|
||||
|
||||
| Port | Name | Type |
|
||||
|------|------|------|
|
||||
| {port} | {name} | {type} |
|
||||
|
||||
**Terminal Commands:**
|
||||
```bash
|
||||
pm2 start ecosystem.config.cjs # İlk seferinde
|
||||
pm2 start all # İlk seferinden sonra
|
||||
pm2 stop all / pm2 restart all
|
||||
pm2 start {name} / pm2 stop {name}
|
||||
pm2 logs / pm2 status / pm2 monit
|
||||
pm2 save # Process listesini kaydet
|
||||
pm2 resurrect # Kaydedilen listeyi geri yükle
|
||||
```
|
||||
````
|
||||
|
||||
**CLAUDE.md güncelleme kuralları:**
|
||||
- PM2 bölümü varsa, değiştir
|
||||
- Yoksa, sona ekle
|
||||
- İçeriği minimal ve temel tut
|
||||
|
||||
---
|
||||
|
||||
## Post-Init: Özet Göster
|
||||
|
||||
Tüm dosyalar oluşturulduktan sonra, çıktı:
|
||||
|
||||
```
|
||||
## PM2 Init Complete
|
||||
|
||||
**Services:**
|
||||
|
||||
| Port | Name | Type |
|
||||
|------|------|------|
|
||||
| {port} | {name} | {type} |
|
||||
|
||||
**Claude Commands:** /pm2-all, /pm2-all-stop, /pm2-{port}, /pm2-{port}-stop, /pm2-logs, /pm2-status
|
||||
|
||||
**Terminal Commands:**
|
||||
## İlk seferinde (config dosyasıyla)
|
||||
pm2 start ecosystem.config.cjs && pm2 save
|
||||
|
||||
## İlk seferinden sonra (basitleştirilmiş)
|
||||
pm2 start all # Hepsini başlat
|
||||
pm2 stop all # Hepsini durdur
|
||||
pm2 restart all # Hepsini yeniden başlat
|
||||
pm2 start {name} # Tekli başlat
|
||||
pm2 stop {name} # Tekli durdur
|
||||
pm2 logs # Logları göster
|
||||
pm2 monit # Monitor paneli
|
||||
pm2 resurrect # Kaydedilen process'leri geri yükle
|
||||
|
||||
**İpucu:** Basitleştirilmiş komutları etkinleştirmek için ilk başlatmadan sonra `pm2 save` çalıştırın.
|
||||
```
|
||||
80
docs/tr/commands/refactor-clean.md
Normal file
80
docs/tr/commands/refactor-clean.md
Normal file
@@ -0,0 +1,80 @@
|
||||
# Refactor Clean
|
||||
|
||||
Her adımda test doğrulaması ile ölü kodu güvenle tanımla ve kaldır.
|
||||
|
||||
## Adım 1: Ölü Kodu Tespit Et
|
||||
|
||||
Proje türüne göre analiz araçlarını çalıştır:
|
||||
|
||||
| Araç | Ne Bulur | Komut |
|
||||
|------|--------------|---------|
|
||||
| knip | Kullanılmayan export'lar, dosyalar, bağımlılıklar | `npx knip` |
|
||||
| depcheck | Kullanılmayan npm bağımlılıkları | `npx depcheck` |
|
||||
| ts-prune | Kullanılmayan TypeScript export'ları | `npx ts-prune` |
|
||||
| vulture | Kullanılmayan Python kodu | `vulture src/` |
|
||||
| deadcode | Kullanılmayan Go kodu | `deadcode ./...` |
|
||||
| cargo-udeps | Kullanılmayan Rust bağımlılıkları | `cargo +nightly udeps` |
|
||||
|
||||
Hiçbir araç yoksa, sıfır import'lu export'ları bulmak için Grep kullanın:
|
||||
```
|
||||
# Export'ları bul, sonra herhangi bir yerde import edilip edilmediklerini kontrol et
|
||||
```
|
||||
|
||||
## Adım 2: Bulguları Kategorize Et
|
||||
|
||||
Bulguları güvenlik katmanlarına göre sırala:
|
||||
|
||||
| Katman | Örnekler | Aksiyon |
|
||||
|------|----------|--------|
|
||||
| **GÜVENLİ** | Kullanılmayan yardımcılar, test yardımcıları, dahili fonksiyonlar | Güvenle sil |
|
||||
| **DİKKAT** | Component'ler, API route'ları, middleware | Dinamik import'ları veya harici tüketicileri olmadığını doğrula |
|
||||
| **TEHLİKE** | Config dosyaları, giriş noktaları, tip tanımları | Dokunmadan önce araştır |
|
||||
|
||||
## Adım 3: Güvenli Silme Döngüsü
|
||||
|
||||
Her GÜVENLİ öğe için:
|
||||
|
||||
1. **Tam test paketini çalıştır** — Baseline oluştur (tümü yeşil)
|
||||
2. **Ölü kodu sil** — Cerrahi kaldırma için Edit aracını kullan
|
||||
3. **Test paketini yeniden çalıştır** — Hiçbir şeyin bozulmadığını doğrula
|
||||
4. **Testler başarısız olursa** — Hemen `git checkout -- <file>` ile geri al ve bu öğeyi atla
|
||||
5. **Testler geçerse** — Sonraki öğeye geç
|
||||
|
||||
## Adım 4: DİKKAT Öğelerini İdare Et
|
||||
|
||||
DİKKAT öğelerini silmeden önce:
|
||||
- Dinamik import'ları ara: `import()`, `require()`, `__import__`
|
||||
- String referansları ara: route isimleri, config'lerdeki component isimleri
|
||||
- Public paket API'sinden export edilip edilmediğini kontrol et
|
||||
- Harici tüketici olmadığını doğrula (yayınlanmışsa bağımlıları kontrol et)
|
||||
|
||||
## Adım 5: Duplikatları Birleştir
|
||||
|
||||
Ölü kodu kaldırdıktan sonra şunları ara:
|
||||
- Neredeyse aynı fonksiyonlar (%80'den fazla benzer) — birinde birleştir
|
||||
- Gereksiz tip tanımları — birleştir
|
||||
- Değer eklemeyen wrapper fonksiyonlar — inline yap
|
||||
- Amacı olmayan re-export'lar — yönlendirmeyi kaldır
|
||||
|
||||
## Adım 6: Özet
|
||||
|
||||
Sonuçları raporla:
|
||||
|
||||
```
|
||||
Ölü Kod Temizliği
|
||||
──────────────────────────────
|
||||
Silindi: 12 kullanılmayan fonksiyon
|
||||
3 kullanılmayan dosya
|
||||
5 kullanılmayan bağımlılık
|
||||
Atlandı: 2 öğe (testler başarısız)
|
||||
Kazanç: ~450 satır kaldırıldı
|
||||
──────────────────────────────
|
||||
Tüm testler geçiyor ✅
|
||||
```
|
||||
|
||||
## Kurallar
|
||||
|
||||
- **Önce testleri çalıştırmadan asla silmeyin**
|
||||
- **Bir seferde bir silme** — Atomik değişiklikler geri almayı kolaylaştırır
|
||||
- **Emin değilseniz atlayın** — Üretimi bozmaktansa ölü kodu tutmak daha iyidir
|
||||
- **Temizlerken refactor etmeyin** — Endişeleri ayırın (önce temizle, sonra refactor et)
|
||||
293
docs/tr/commands/sessions.md
Normal file
293
docs/tr/commands/sessions.md
Normal file
@@ -0,0 +1,293 @@
|
||||
---
|
||||
description: Claude Code session geçmişini, aliasları ve session metadata'sını yönet.
|
||||
---
|
||||
|
||||
# Sessions Komutu
|
||||
|
||||
Claude Code session geçmişini yönet - `~/.claude/sessions/` dizininde saklanan session'ları listele, yükle, alias ata ve düzenle.
|
||||
|
||||
## Kullanım
|
||||
|
||||
`/sessions [list|load|alias|info|help] [options]`
|
||||
|
||||
## Aksiyonlar
|
||||
|
||||
### List Sessions
|
||||
|
||||
Tüm session'ları metadata, filtreleme ve sayfalama ile göster.
|
||||
|
||||
Bir swarm için operatör-yüzey context'e ihtiyacınız olduğunda `/sessions info` kullanın: branch, worktree yolu ve session güncelliği.
|
||||
|
||||
```bash
|
||||
/sessions # Tüm session'ları listele (varsayılan)
|
||||
/sessions list # Yukarıdakiyle aynı
|
||||
/sessions list --limit 10 # 10 session göster
|
||||
/sessions list --date 2026-02-01 # Tarihe göre filtrele
|
||||
/sessions list --search abc # Session ID'ye göre ara
|
||||
```
|
||||
|
||||
**Script:**
|
||||
```bash
|
||||
node -e "
|
||||
const sm = require((()=>{var e=process.env.CLAUDE_PLUGIN_ROOT;if(e&&e.trim())return e.trim();var p=require('path'),f=require('fs'),h=require('os').homedir(),d=p.join(h,'.claude'),q=p.join('scripts','lib','utils.js');if(f.existsSync(p.join(d,q)))return d;try{var b=p.join(d,'plugins','cache','everything-claude-code');for(var o of f.readdirSync(b))for(var v of f.readdirSync(p.join(b,o))){var c=p.join(b,o,v);if(f.existsSync(p.join(c,q)))return c}}catch(x){}return d})()+'/scripts/lib/session-manager');
|
||||
const aa = require((()=>{var e=process.env.CLAUDE_PLUGIN_ROOT;if(e&&e.trim())return e.trim();var p=require('path'),f=require('fs'),h=require('os').homedir(),d=p.join(h,'.claude'),q=p.join('scripts','lib','utils.js');if(f.existsSync(p.join(d,q)))return d;try{var b=p.join(d,'plugins','cache','everything-claude-code');for(var o of f.readdirSync(b))for(var v of f.readdirSync(p.join(b,o))){var c=p.join(b,o,v);if(f.existsSync(p.join(c,q)))return c}}catch(x){}return d})()+'/scripts/lib/session-aliases');
|
||||
const path = require('path');
|
||||
|
||||
const result = sm.getAllSessions({ limit: 20 });
|
||||
const aliases = aa.listAliases();
|
||||
const aliasMap = {};
|
||||
for (const a of aliases) aliasMap[a.sessionPath] = a.name;
|
||||
|
||||
console.log('Sessions (showing ' + result.sessions.length + ' of ' + result.total + '):');
|
||||
console.log('');
|
||||
console.log('ID Date Time Branch Worktree Alias');
|
||||
console.log('────────────────────────────────────────────────────────────────────');
|
||||
|
||||
for (const s of result.sessions) {
|
||||
const alias = aliasMap[s.filename] || '';
|
||||
const metadata = sm.parseSessionMetadata(sm.getSessionContent(s.sessionPath));
|
||||
const id = s.shortId === 'no-id' ? '(none)' : s.shortId.slice(0, 8);
|
||||
const time = s.modifiedTime.toTimeString().slice(0, 5);
|
||||
const branch = (metadata.branch || '-').slice(0, 12);
|
||||
const worktree = metadata.worktree ? path.basename(metadata.worktree).slice(0, 18) : '-';
|
||||
|
||||
console.log(id.padEnd(8) + ' ' + s.date + ' ' + time + ' ' + branch.padEnd(12) + ' ' + worktree.padEnd(18) + ' ' + alias);
|
||||
}
|
||||
"
|
||||
```
|
||||
|
||||
### Load Session
|
||||
|
||||
Session içeriğini yükle ve göster (ID veya alias ile).
|
||||
|
||||
```bash
|
||||
/sessions load <id|alias> # Session yükle
|
||||
/sessions load 2026-02-01 # Tarihe göre (no-id session'lar için)
|
||||
/sessions load a1b2c3d4 # Short ID ile
|
||||
/sessions load my-alias # Alias adıyla
|
||||
```
|
||||
|
||||
**Script:**
|
||||
```bash
|
||||
node -e "
|
||||
const sm = require((()=>{var e=process.env.CLAUDE_PLUGIN_ROOT;if(e&&e.trim())return e.trim();var p=require('path'),f=require('fs'),h=require('os').homedir(),d=p.join(h,'.claude'),q=p.join('scripts','lib','utils.js');if(f.existsSync(p.join(d,q)))return d;try{var b=p.join(d,'plugins','cache','everything-claude-code');for(var o of f.readdirSync(b))for(var v of f.readdirSync(p.join(b,o))){var c=p.join(b,o,v);if(f.existsSync(p.join(c,q)))return c}}catch(x){}return d})()+'/scripts/lib/session-manager');
|
||||
const aa = require((()=>{var e=process.env.CLAUDE_PLUGIN_ROOT;if(e&&e.trim())return e.trim();var p=require('path'),f=require('fs'),h=require('os').homedir(),d=p.join(h,'.claude'),q=p.join('scripts','lib','utils.js');if(f.existsSync(p.join(d,q)))return d;try{var b=p.join(d,'plugins','cache','everything-claude-code');for(var o of f.readdirSync(b))for(var v of f.readdirSync(p.join(b,o))){var c=p.join(b,o,v);if(f.existsSync(p.join(c,q)))return c}}catch(x){}return d})()+'/scripts/lib/session-aliases');
|
||||
const id = process.argv[1];
|
||||
|
||||
// Önce alias olarak çözümlemeyi dene
|
||||
const resolved = aa.resolveAlias(id);
|
||||
const sessionId = resolved ? resolved.sessionPath : id;
|
||||
|
||||
const session = sm.getSessionById(sessionId, true);
|
||||
if (!session) {
|
||||
console.log('Session not found: ' + id);
|
||||
process.exit(1);
|
||||
}
|
||||
|
||||
const stats = sm.getSessionStats(session.sessionPath);
|
||||
const size = sm.getSessionSize(session.sessionPath);
|
||||
const aliases = aa.getAliasesForSession(session.filename);
|
||||
|
||||
console.log('Session: ' + session.filename);
|
||||
console.log('Path: ~/.claude/sessions/' + session.filename);
|
||||
console.log('');
|
||||
console.log('Statistics:');
|
||||
console.log(' Lines: ' + stats.lineCount);
|
||||
console.log(' Total items: ' + stats.totalItems);
|
||||
console.log(' Completed: ' + stats.completedItems);
|
||||
console.log(' In progress: ' + stats.inProgressItems);
|
||||
console.log(' Size: ' + size);
|
||||
console.log('');
|
||||
|
||||
if (aliases.length > 0) {
|
||||
console.log('Aliases: ' + aliases.map(a => a.name).join(', '));
|
||||
console.log('');
|
||||
}
|
||||
|
||||
if (session.metadata.title) {
|
||||
console.log('Title: ' + session.metadata.title);
|
||||
console.log('');
|
||||
}
|
||||
|
||||
if (session.metadata.started) {
|
||||
console.log('Started: ' + session.metadata.started);
|
||||
}
|
||||
|
||||
if (session.metadata.lastUpdated) {
|
||||
console.log('Last Updated: ' + session.metadata.lastUpdated);
|
||||
}
|
||||
|
||||
if (session.metadata.project) {
|
||||
console.log('Project: ' + session.metadata.project);
|
||||
}
|
||||
|
||||
if (session.metadata.branch) {
|
||||
console.log('Branch: ' + session.metadata.branch);
|
||||
}
|
||||
|
||||
if (session.metadata.worktree) {
|
||||
console.log('Worktree: ' + session.metadata.worktree);
|
||||
}
|
||||
" "$ARGUMENTS"
|
||||
```
|
||||
|
||||
### Create Alias
|
||||
|
||||
Session için akılda kalıcı bir alias oluştur.
|
||||
|
||||
```bash
|
||||
/sessions alias <id> <name> # Alias oluştur
|
||||
/sessions alias 2026-02-01 today-work # "today-work" adlı alias oluştur
|
||||
```
|
||||
|
||||
**Script:**
|
||||
```bash
|
||||
node -e "
|
||||
const sm = require((()=>{var e=process.env.CLAUDE_PLUGIN_ROOT;if(e&&e.trim())return e.trim();var p=require('path'),f=require('fs'),h=require('os').homedir(),d=p.join(h,'.claude'),q=p.join('scripts','lib','utils.js');if(f.existsSync(p.join(d,q)))return d;try{var b=p.join(d,'plugins','cache','everything-claude-code');for(var o of f.readdirSync(b))for(var v of f.readdirSync(p.join(b,o))){var c=p.join(b,o,v);if(f.existsSync(p.join(c,q)))return c}}catch(x){}return d})()+'/scripts/lib/session-manager');
|
||||
const aa = require((()=>{var e=process.env.CLAUDE_PLUGIN_ROOT;if(e&&e.trim())return e.trim();var p=require('path'),f=require('fs'),h=require('os').homedir(),d=p.join(h,'.claude'),q=p.join('scripts','lib','utils.js');if(f.existsSync(p.join(d,q)))return d;try{var b=p.join(d,'plugins','cache','everything-claude-code');for(var o of f.readdirSync(b))for(var v of f.readdirSync(p.join(b,o))){var c=p.join(b,o,v);if(f.existsSync(p.join(c,q)))return c}}catch(x){}return d})()+'/scripts/lib/session-aliases');
|
||||
|
||||
const sessionId = process.argv[1];
|
||||
const aliasName = process.argv[2];
|
||||
|
||||
if (!sessionId || !aliasName) {
|
||||
console.log('Usage: /sessions alias <id> <name>');
|
||||
process.exit(1);
|
||||
}
|
||||
|
||||
// Session dosya adını al
|
||||
const session = sm.getSessionById(sessionId);
|
||||
if (!session) {
|
||||
console.log('Session not found: ' + sessionId);
|
||||
process.exit(1);
|
||||
}
|
||||
|
||||
const result = aa.setAlias(aliasName, session.filename);
|
||||
if (result.success) {
|
||||
console.log('✓ Alias created: ' + aliasName + ' → ' + session.filename);
|
||||
} else {
|
||||
console.log('✗ Error: ' + result.error);
|
||||
process.exit(1);
|
||||
}
|
||||
" "$ARGUMENTS"
|
||||
```
|
||||
|
||||
### Remove Alias
|
||||
|
||||
Mevcut bir alias'ı sil.
|
||||
|
||||
```bash
|
||||
/sessions alias --remove <name> # Alias'ı kaldır
|
||||
/sessions unalias <name> # Yukarıdakiyle aynı
|
||||
```
|
||||
|
||||
**Script:**
|
||||
```bash
|
||||
node -e "
|
||||
const aa = require((()=>{var e=process.env.CLAUDE_PLUGIN_ROOT;if(e&&e.trim())return e.trim();var p=require('path'),f=require('fs'),h=require('os').homedir(),d=p.join(h,'.claude'),q=p.join('scripts','lib','utils.js');if(f.existsSync(p.join(d,q)))return d;try{var b=p.join(d,'plugins','cache','everything-claude-code');for(var o of f.readdirSync(b))for(var v of f.readdirSync(p.join(b,o))){var c=p.join(b,o,v);if(f.existsSync(p.join(c,q)))return c}}catch(x){}return d})()+'/scripts/lib/session-aliases');
|
||||
|
||||
const aliasName = process.argv[1];
|
||||
if (!aliasName) {
|
||||
console.log('Usage: /sessions alias --remove <name>');
|
||||
process.exit(1);
|
||||
}
|
||||
|
||||
const result = aa.deleteAlias(aliasName);
|
||||
if (result.success) {
|
||||
console.log('✓ Alias removed: ' + aliasName);
|
||||
} else {
|
||||
console.log('✗ Error: ' + result.error);
|
||||
process.exit(1);
|
||||
}
|
||||
" "$ARGUMENTS"
|
||||
```
|
||||
|
||||
### Session Info
|
||||
|
||||
Session hakkında detaylı bilgi göster.
|
||||
|
||||
```bash
|
||||
/sessions info <id|alias> # Session detaylarını göster
|
||||
```
|
||||
|
||||
**Script:** (yukarıdaki Load Session script'i ile aynı yapı)
|
||||
|
||||
### List Aliases
|
||||
|
||||
Tüm session aliaslarını göster.
|
||||
|
||||
```bash
|
||||
/sessions aliases # Tüm aliasları listele
|
||||
```
|
||||
|
||||
**Script:**
|
||||
```bash
|
||||
node -e "
|
||||
const aa = require((()=>{var e=process.env.CLAUDE_PLUGIN_ROOT;if(e&&e.trim())return e.trim();var p=require('path'),f=require('fs'),h=require('os').homedir(),d=p.join(h,'.claude'),q=p.join('scripts','lib','utils.js');if(f.existsSync(p.join(d,q)))return d;try{var b=p.join(d,'plugins','cache','everything-claude-code');for(var o of f.readdirSync(b))for(var v of f.readdirSync(p.join(b,o))){var c=p.join(b,o,v);if(f.existsSync(p.join(c,q)))return c}}catch(x){}return d})()+'/scripts/lib/session-aliases');
|
||||
|
||||
const aliases = aa.listAliases();
|
||||
console.log('Session Aliases (' + aliases.length + '):');
|
||||
console.log('');
|
||||
|
||||
if (aliases.length === 0) {
|
||||
console.log('No aliases found.');
|
||||
} else {
|
||||
console.log('Name Session File Title');
|
||||
console.log('─────────────────────────────────────────────────────────────');
|
||||
for (const a of aliases) {
|
||||
const name = a.name.padEnd(12);
|
||||
const file = (a.sessionPath.length > 30 ? a.sessionPath.slice(0, 27) + '...' : a.sessionPath).padEnd(30);
|
||||
const title = a.title || '';
|
||||
console.log(name + ' ' + file + ' ' + title);
|
||||
}
|
||||
}
|
||||
"
|
||||
```
|
||||
|
||||
## Operatör Notları
|
||||
|
||||
- Session dosyaları header'da `Project`, `Branch` ve `Worktree`'yi sürdürür, böylece `/sessions info` parallel tmux/worktree çalıştırmalarını ayırt edebilir.
|
||||
- Command-center tarzı izleme için, `/sessions info`, `git diff --stat` ve `scripts/hooks/cost-tracker.js` tarafından yayılan cost metriklerini birleştirin.
|
||||
|
||||
## Argümanlar
|
||||
|
||||
$ARGUMENTS:
|
||||
- `list [options]` - Session'ları listele
|
||||
- `--limit <n>` - Gösterilecek max session (varsayılan: 50)
|
||||
- `--date <YYYY-MM-DD>` - Tarihe göre filtrele
|
||||
- `--search <pattern>` - Session ID'de ara
|
||||
- `load <id|alias>` - Session içeriğini yükle
|
||||
- `alias <id> <name>` - Session için alias oluştur
|
||||
- `alias --remove <name>` - Alias'ı kaldır
|
||||
- `unalias <name>` - `--remove` ile aynı
|
||||
- `info <id|alias>` - Session istatistiklerini göster
|
||||
- `aliases` - Tüm aliasları listele
|
||||
- `help` - Bu yardımı göster
|
||||
|
||||
## Örnekler
|
||||
|
||||
```bash
|
||||
# Tüm session'ları listele
|
||||
/sessions list
|
||||
|
||||
# Bugünkü session için alias oluştur
|
||||
/sessions alias 2026-02-01 today
|
||||
|
||||
# Session'ı alias ile yükle
|
||||
/sessions load today
|
||||
|
||||
# Session bilgisini göster
|
||||
/sessions info today
|
||||
|
||||
# Alias'ı kaldır
|
||||
/sessions alias --remove today
|
||||
|
||||
# Tüm aliasları listele
|
||||
/sessions aliases
|
||||
```
|
||||
|
||||
## Notlar
|
||||
|
||||
- Session'lar `~/.claude/sessions/` dizininde markdown dosyaları olarak saklanır
|
||||
- Aliaslar `~/.claude/session-aliases.json` dosyasında saklanır
|
||||
- Session ID'leri kısaltılabilir (ilk 4-8 karakter genellikle yeterince benzersizdir)
|
||||
- Sık referans verilen session'lar için aliasları kullanın
|
||||
80
docs/tr/commands/setup-pm.md
Normal file
80
docs/tr/commands/setup-pm.md
Normal file
@@ -0,0 +1,80 @@
|
||||
---
|
||||
description: Tercih ettiğiniz paket yöneticisini yapılandırın (npm/pnpm/yarn/bun)
|
||||
disable-model-invocation: true
|
||||
---
|
||||
|
||||
# Paket Yöneticisi Kurulumu
|
||||
|
||||
Bu proje veya global olarak tercih ettiğiniz paket yöneticisini yapılandırın.
|
||||
|
||||
## Kullanım
|
||||
|
||||
```bash
|
||||
# Mevcut paket yöneticisini tespit et
|
||||
node scripts/setup-package-manager.js --detect
|
||||
|
||||
# Global tercihi ayarla
|
||||
node scripts/setup-package-manager.js --global pnpm
|
||||
|
||||
# Proje tercihini ayarla
|
||||
node scripts/setup-package-manager.js --project bun
|
||||
|
||||
# Mevcut paket yöneticilerini listele
|
||||
node scripts/setup-package-manager.js --list
|
||||
```
|
||||
|
||||
## Tespit Önceliği
|
||||
|
||||
Hangi paket yöneticisinin kullanılacağını belirlerken, şu sıra kontrol edilir:
|
||||
|
||||
1. **Environment variable**: `CLAUDE_PACKAGE_MANAGER`
|
||||
2. **Proje config**: `.claude/package-manager.json`
|
||||
3. **package.json**: `packageManager` alanı
|
||||
4. **Lock dosyası**: package-lock.json, yarn.lock, pnpm-lock.yaml veya bun.lockb varlığı
|
||||
5. **Global config**: `~/.claude/package-manager.json`
|
||||
6. **Fallback**: İlk mevcut paket yöneticisi (pnpm > bun > yarn > npm)
|
||||
|
||||
## Yapılandırma Dosyaları
|
||||
|
||||
### Global Yapılandırma
|
||||
```json
|
||||
// ~/.claude/package-manager.json
|
||||
{
|
||||
"packageManager": "pnpm"
|
||||
}
|
||||
```
|
||||
|
||||
### Proje Yapılandırması
|
||||
```json
|
||||
// .claude/package-manager.json
|
||||
{
|
||||
"packageManager": "bun"
|
||||
}
|
||||
```
|
||||
|
||||
### package.json
|
||||
```json
|
||||
{
|
||||
"packageManager": "pnpm@8.6.0"
|
||||
}
|
||||
```
|
||||
|
||||
## Environment Variable
|
||||
|
||||
Tüm diğer tespit yöntemlerini geçersiz kılmak için `CLAUDE_PACKAGE_MANAGER` ayarlayın:
|
||||
|
||||
```bash
|
||||
# Windows (PowerShell)
|
||||
$env:CLAUDE_PACKAGE_MANAGER = "pnpm"
|
||||
|
||||
# macOS/Linux
|
||||
export CLAUDE_PACKAGE_MANAGER=pnpm
|
||||
```
|
||||
|
||||
## Tespiti Çalıştır
|
||||
|
||||
Mevcut paket yöneticisi tespit sonuçlarını görmek için şunu çalıştırın:
|
||||
|
||||
```bash
|
||||
node scripts/setup-package-manager.js --detect
|
||||
```
|
||||
174
docs/tr/commands/skill-create.md
Normal file
174
docs/tr/commands/skill-create.md
Normal file
@@ -0,0 +1,174 @@
|
||||
---
|
||||
name: skill-create
|
||||
description: Kodlama desenlerini çıkarmak ve SKILL.md dosyaları oluşturmak için yerel git geçmişini analiz et. Skill Creator GitHub App'ın yerel versiyonu.
|
||||
allowed_tools: ["Bash", "Read", "Write", "Grep", "Glob"]
|
||||
---
|
||||
|
||||
# /skill-create - Yerel Skill Oluşturma
|
||||
|
||||
Repository'nizin git geçmişini analiz ederek kodlama desenlerini çıkarın ve Claude'a ekibinizin uygulamalarını öğreten SKILL.md dosyaları oluşturun.
|
||||
|
||||
## Kullanım
|
||||
|
||||
```bash
|
||||
/skill-create # Mevcut repo'yu analiz et
|
||||
/skill-create --commits 100 # Son 100 commit'i analiz et
|
||||
/skill-create --output ./skills # Özel çıktı dizini
|
||||
/skill-create --instincts # continuous-learning-v2 için instinct'ler de oluştur
|
||||
```
|
||||
|
||||
## Ne Yapar
|
||||
|
||||
1. **Git Geçmişini Parse Eder** - Commit'leri, dosya değişikliklerini ve desenleri analiz eder
|
||||
2. **Desenleri Tespit Eder** - Tekrarlayan iş akışlarını ve kuralları tanımlar
|
||||
3. **SKILL.md Oluşturur** - Geçerli Claude Code skill dosyaları oluşturur
|
||||
4. **İsteğe Bağlı Instinct'ler Oluşturur** - continuous-learning-v2 sistemi için
|
||||
|
||||
## Analiz Adımları
|
||||
|
||||
### Adım 1: Git Verilerini Topla
|
||||
|
||||
```bash
|
||||
# Dosya değişiklikleriyle son commit'leri al
|
||||
git log --oneline -n ${COMMITS:-200} --name-only --pretty=format:"%H|%s|%ad" --date=short
|
||||
|
||||
# Dosyaya göre commit sıklığını al
|
||||
git log --oneline -n 200 --name-only | grep -v "^$" | grep -v "^[a-f0-9]" | sort | uniq -c | sort -rn | head -20
|
||||
|
||||
# Commit mesaj desenlerini al
|
||||
git log --oneline -n 200 | cut -d' ' -f2- | head -50
|
||||
```
|
||||
|
||||
### Adım 2: Desenleri Tespit Et
|
||||
|
||||
Bu desen türlerini ara:
|
||||
|
||||
| Desen | Tespit Yöntemi |
|
||||
|---------|-----------------|
|
||||
| **Commit kuralları** | Commit mesajlarında regex (feat:, fix:, chore:) |
|
||||
| **Dosya birlikte değişimleri** | Her zaman birlikte değişen dosyalar |
|
||||
| **İş akışı dizileri** | Tekrarlanan dosya değişim desenleri |
|
||||
| **Mimari** | Klasör yapısı ve isimlendirme kuralları |
|
||||
| **Test desenleri** | Test dosya konumları, isimlendirme, kapsama |
|
||||
|
||||
### Adım 3: SKILL.md Oluştur
|
||||
|
||||
Çıktı formatı:
|
||||
|
||||
```markdown
|
||||
---
|
||||
name: {repo-name}-patterns
|
||||
description: {repo-name}'den çıkarılan kodlama desenleri
|
||||
version: 1.0.0
|
||||
source: local-git-analysis
|
||||
analyzed_commits: {count}
|
||||
---
|
||||
|
||||
# {Repo Name} Desenleri
|
||||
|
||||
## Commit Kuralları
|
||||
{tespit edilen commit mesaj desenleri}
|
||||
|
||||
## Kod Mimarisi
|
||||
{tespit edilen klasör yapısı ve organizasyon}
|
||||
|
||||
## İş Akışları
|
||||
{tespit edilen tekrarlayan dosya değişim desenleri}
|
||||
|
||||
## Test Desenleri
|
||||
{tespit edilen test kuralları}
|
||||
```
|
||||
|
||||
### Adım 4: Instinct'ler Oluştur (--instincts varsa)
|
||||
|
||||
continuous-learning-v2 entegrasyonu için:
|
||||
|
||||
```yaml
|
||||
---
|
||||
id: {repo}-commit-convention
|
||||
trigger: "bir commit mesajı yazarken"
|
||||
confidence: 0.8
|
||||
domain: git
|
||||
source: local-repo-analysis
|
||||
---
|
||||
|
||||
# Conventional Commits Kullan
|
||||
|
||||
## Aksiyon
|
||||
Commit'leri şu öneklerle başlat: feat:, fix:, chore:, docs:, test:, refactor:
|
||||
|
||||
## Kanıt
|
||||
- {n} commit analiz edildi
|
||||
- {percentage}% conventional commit formatını takip ediyor
|
||||
```
|
||||
|
||||
## Örnek Çıktı
|
||||
|
||||
Bir TypeScript projesinde `/skill-create` çalıştırmak şunları üretebilir:
|
||||
|
||||
```markdown
|
||||
---
|
||||
name: my-app-patterns
|
||||
description: my-app repository'sinden kodlama desenleri
|
||||
version: 1.0.0
|
||||
source: local-git-analysis
|
||||
analyzed_commits: 150
|
||||
---
|
||||
|
||||
# My App Desenleri
|
||||
|
||||
## Commit Kuralları
|
||||
|
||||
Bu proje **conventional commits** kullanıyor:
|
||||
- `feat:` - Yeni özellikler
|
||||
- `fix:` - Hata düzeltmeleri
|
||||
- `chore:` - Bakım görevleri
|
||||
- `docs:` - Dokümantasyon güncellemeleri
|
||||
|
||||
## Kod Mimarisi
|
||||
|
||||
```
|
||||
src/
|
||||
├── components/ # React componentleri (PascalCase.tsx)
|
||||
├── hooks/ # Özel hook'lar (use*.ts)
|
||||
├── utils/ # Yardımcı fonksiyonlar
|
||||
├── types/ # TypeScript tip tanımları
|
||||
└── services/ # API ve harici servisler
|
||||
```
|
||||
|
||||
## İş Akışları
|
||||
|
||||
### Yeni Bir Component Ekleme
|
||||
1. `src/components/ComponentName.tsx` oluştur
|
||||
2. `src/components/__tests__/ComponentName.test.tsx`'de testler ekle
|
||||
3. `src/components/index.ts`'den export et
|
||||
|
||||
### Database Migration
|
||||
1. `src/db/schema.ts`'yi değiştir
|
||||
2. `pnpm db:generate` çalıştır
|
||||
3. `pnpm db:migrate` çalıştır
|
||||
|
||||
## Test Desenleri
|
||||
|
||||
- Test dosyaları: `__tests__/` dizinleri veya `.test.ts` eki
|
||||
- Kapsama hedefi: 80%+
|
||||
- Framework: Vitest
|
||||
```
|
||||
|
||||
## GitHub App Entegrasyonu
|
||||
|
||||
Gelişmiş özellikler için (10k+ commit, ekip paylaşımı, otomatik PR'lar), [Skill Creator GitHub App](https://github.com/apps/skill-creator) kullanın:
|
||||
|
||||
- Yükle: [github.com/apps/skill-creator](https://github.com/apps/skill-creator)
|
||||
- Herhangi bir issue'da `/skill-creator analyze` yorumu yap
|
||||
- Oluşturulan skill'lerle PR alın
|
||||
|
||||
## İlgili Komutlar
|
||||
|
||||
- `/instinct-import` - Oluşturulan instinct'leri import et
|
||||
- `/instinct-status` - Öğrenilen instinct'leri görüntüle
|
||||
- `/evolve` - Instinct'leri skill'ler/agent'lara kümelendir
|
||||
|
||||
---
|
||||
|
||||
*[Everything Claude Code](https://github.com/affaan-m/everything-claude-code)'un bir parçası*
|
||||
328
docs/tr/commands/tdd.md
Normal file
328
docs/tr/commands/tdd.md
Normal file
@@ -0,0 +1,328 @@
|
||||
---
|
||||
description: Test odaklı geliştirme (TDD) iş akışını zorlar. Interface'leri tasarla, ÖNCE testleri oluştur, sonra minimal kodu uygula. %80+ kod kapsama oranı sağla.
|
||||
---
|
||||
|
||||
# TDD Komutu
|
||||
|
||||
Bu komut, test odaklı geliştirme metodolojisini zorlamak için **tdd-guide** agent'ını çağırır.
|
||||
|
||||
## Bu Komut Ne Yapar
|
||||
|
||||
1. **Interface'leri Tasarla** - Önce tip/interface'leri tanımla
|
||||
2. **Önce Testleri Oluştur** - Başarısız testler yaz (RED)
|
||||
3. **Minimal Kod Uygula** - Geçmek için yeterli kodu yaz (GREEN)
|
||||
4. **Refactor Et** - Testleri yeşil tutarken kodu iyileştir (REFACTOR)
|
||||
5. **Kapsama Oranını Doğrula** - %80+ test kapsama oranı sağla
|
||||
|
||||
## Ne Zaman Kullanılır
|
||||
|
||||
`/tdd` komutunu şu durumlarda kullanın:
|
||||
- Yeni özellikler uygularken
|
||||
- Yeni fonksiyonlar/componentler eklerken
|
||||
- Hataları düzeltirken (önce hatayı tekrar eden test yaz)
|
||||
- Mevcut kodu refactor ederken
|
||||
- Kritik iş mantığı oluştururken
|
||||
|
||||
## Nasıl Çalışır
|
||||
|
||||
tdd-guide agent'ı şunları yapacaktır:
|
||||
|
||||
1. Giriş/çıkışlar için **interface'leri tanımla**
|
||||
2. **BAŞARISIZ olacak testleri yaz** (çünkü kod henüz yok)
|
||||
3. **Testleri çalıştır** ve doğru sebepten başarısız olduklarını doğrula
|
||||
4. Testleri geçirmek için **minimal uygulama yaz**
|
||||
5. **Testleri çalıştır** ve geçtiklerini doğrula
|
||||
6. Testleri yeşil tutarken kodu **refactor et**
|
||||
7. **Kapsama oranını kontrol et** ve %80'in altındaysa daha fazla test ekle
|
||||
|
||||
## TDD Döngüsü
|
||||
|
||||
```
|
||||
RED → GREEN → REFACTOR → TEKRARLA
|
||||
|
||||
RED: Başarısız bir test yaz
|
||||
GREEN: Geçmek için minimal kod yaz
|
||||
REFACTOR: Kodu iyileştir, testleri geçmeye devam et
|
||||
TEKRARLA: Bir sonraki özellik/senaryo
|
||||
```
|
||||
|
||||
## Örnek Kullanım
|
||||
|
||||
```
|
||||
Kullanıcı: /tdd Piyasa likidite skorunu hesaplamak için bir fonksiyona ihtiyacım var
|
||||
|
||||
Agent (tdd-guide):
|
||||
# TDD Oturumu: Piyasa Likidite Skoru Hesaplayıcı
|
||||
|
||||
## Adım 1: Interface Tanımla (SCAFFOLD)
|
||||
|
||||
```typescript
|
||||
// lib/liquidity.ts
|
||||
export interface MarketData {
|
||||
totalVolume: number
|
||||
bidAskSpread: number
|
||||
activeTraders: number
|
||||
lastTradeTime: Date
|
||||
}
|
||||
|
||||
export function calculateLiquidityScore(market: MarketData): number {
|
||||
// TODO: Uygulama
|
||||
throw new Error('Not implemented')
|
||||
}
|
||||
```
|
||||
|
||||
## Adım 2: Başarısız Test Yaz (RED)
|
||||
|
||||
```typescript
|
||||
// lib/liquidity.test.ts
|
||||
import { calculateLiquidityScore } from './liquidity'
|
||||
|
||||
describe('calculateLiquidityScore', () => {
|
||||
it('likit piyasa için yüksek skor döndürmeli', () => {
|
||||
const market = {
|
||||
totalVolume: 100000,
|
||||
bidAskSpread: 0.01,
|
||||
activeTraders: 500,
|
||||
lastTradeTime: new Date()
|
||||
}
|
||||
|
||||
const score = calculateLiquidityScore(market)
|
||||
|
||||
expect(score).toBeGreaterThan(80)
|
||||
expect(score).toBeLessThanOrEqual(100)
|
||||
})
|
||||
|
||||
it('az likit piyasa için düşük skor döndürmeli', () => {
|
||||
const market = {
|
||||
totalVolume: 100,
|
||||
bidAskSpread: 0.5,
|
||||
activeTraders: 2,
|
||||
lastTradeTime: new Date(Date.now() - 86400000) // 1 gün önce
|
||||
}
|
||||
|
||||
const score = calculateLiquidityScore(market)
|
||||
|
||||
expect(score).toBeLessThan(30)
|
||||
expect(score).toBeGreaterThanOrEqual(0)
|
||||
})
|
||||
|
||||
it('edge case\'i idare etmeli: sıfır hacim', () => {
|
||||
const market = {
|
||||
totalVolume: 0,
|
||||
bidAskSpread: 0,
|
||||
activeTraders: 0,
|
||||
lastTradeTime: new Date()
|
||||
}
|
||||
|
||||
const score = calculateLiquidityScore(market)
|
||||
|
||||
expect(score).toBe(0)
|
||||
})
|
||||
})
|
||||
```
|
||||
|
||||
## Adım 3: Testleri Çalıştır - Başarısızlığı Doğrula
|
||||
|
||||
```bash
|
||||
npm test lib/liquidity.test.ts
|
||||
|
||||
FAIL lib/liquidity.test.ts
|
||||
✕ should return high score for liquid market (2 ms)
|
||||
Error: Not implemented
|
||||
|
||||
1 test failed, 0 passed
|
||||
```
|
||||
|
||||
✅ Testler beklendiği gibi başarısız. Uygulamaya hazır.
|
||||
|
||||
## Adım 4: Minimal Kod Uygula (GREEN)
|
||||
|
||||
```typescript
|
||||
// lib/liquidity.ts
|
||||
export function calculateLiquidityScore(market: MarketData): number {
|
||||
// Sıfır hacim edge case'ini idare et
|
||||
if (market.totalVolume === 0) {
|
||||
return 0
|
||||
}
|
||||
|
||||
// Bileşen skorlarını hesapla (0-100 ölçeği)
|
||||
const volumeScore = Math.min(market.totalVolume / 1000, 100)
|
||||
const spreadScore = Math.max(100 - (market.bidAskSpread * 1000), 0)
|
||||
const traderScore = Math.min(market.activeTraders / 10, 100)
|
||||
|
||||
// Son aktivite bonusu
|
||||
const hoursSinceLastTrade = (Date.now() - market.lastTradeTime.getTime()) / (1000 * 60 * 60)
|
||||
const recencyScore = Math.max(100 - (hoursSinceLastTrade * 10), 0)
|
||||
|
||||
// Ağırlıklı ortalama
|
||||
const score = (
|
||||
volumeScore * 0.4 +
|
||||
spreadScore * 0.3 +
|
||||
traderScore * 0.2 +
|
||||
recencyScore * 0.1
|
||||
)
|
||||
|
||||
return Math.min(Math.max(score, 0), 100) // 0-100 arası sınırla
|
||||
}
|
||||
```
|
||||
|
||||
## Adım 5: Testleri Çalıştır - Başarıyı Doğrula
|
||||
|
||||
```bash
|
||||
npm test lib/liquidity.test.ts
|
||||
|
||||
PASS lib/liquidity.test.ts
|
||||
✓ should return high score for liquid market (3 ms)
|
||||
✓ should return low score for illiquid market (2 ms)
|
||||
✓ should handle edge case: zero volume (1 ms)
|
||||
|
||||
3 tests passed
|
||||
```
|
||||
|
||||
✅ Tüm testler geçiyor!
|
||||
|
||||
## Adım 6: Refactor Et (IYILEŞTIR)
|
||||
|
||||
```typescript
|
||||
// lib/liquidity.ts - Sabitler ve daha iyi okunabilirlik ile refactor edildi
|
||||
const WEIGHTS = {
|
||||
VOLUME: 0.4,
|
||||
SPREAD: 0.3,
|
||||
TRADERS: 0.2,
|
||||
RECENCY: 0.1,
|
||||
} as const
|
||||
|
||||
const SCALE_FACTORS = {
|
||||
VOLUME: 1000,
|
||||
SPREAD: 1000,
|
||||
TRADERS: 10,
|
||||
RECENCY_PENALTY: 10,
|
||||
} as const
|
||||
|
||||
function clamp(value: number, min: number, max: number): number {
|
||||
return Math.min(Math.max(value, min), max)
|
||||
}
|
||||
|
||||
export function calculateLiquidityScore(market: MarketData): number {
|
||||
if (market.totalVolume === 0) return 0
|
||||
|
||||
const volumeScore = Math.min(market.totalVolume / SCALE_FACTORS.VOLUME, 100)
|
||||
const spreadScore = clamp(100 - (market.bidAskSpread * SCALE_FACTORS.SPREAD), 0, 100)
|
||||
const traderScore = Math.min(market.activeTraders / SCALE_FACTORS.TRADERS, 100)
|
||||
|
||||
const hoursSinceLastTrade = (Date.now() - market.lastTradeTime.getTime()) / (1000 * 60 * 60)
|
||||
const recencyScore = clamp(100 - (hoursSinceLastTrade * SCALE_FACTORS.RECENCY_PENALTY), 0, 100)
|
||||
|
||||
const weightedScore =
|
||||
volumeScore * WEIGHTS.VOLUME +
|
||||
spreadScore * WEIGHTS.SPREAD +
|
||||
traderScore * WEIGHTS.TRADERS +
|
||||
recencyScore * WEIGHTS.RECENCY
|
||||
|
||||
return clamp(weightedScore, 0, 100)
|
||||
}
|
||||
```
|
||||
|
||||
## Adım 7: Testlerin Hala Geçtiğini Doğrula
|
||||
|
||||
```bash
|
||||
npm test lib/liquidity.test.ts
|
||||
|
||||
PASS lib/liquidity.test.ts
|
||||
✓ should return high score for liquid market (3 ms)
|
||||
✓ should return low score for illiquid market (2 ms)
|
||||
✓ should handle edge case: zero volume (1 ms)
|
||||
|
||||
3 tests passed
|
||||
```
|
||||
|
||||
✅ Refactoring tamamlandı, testler hala geçiyor!
|
||||
|
||||
## Adım 8: Kapsama Oranını Kontrol Et
|
||||
|
||||
```bash
|
||||
npm test -- --coverage lib/liquidity.test.ts
|
||||
|
||||
File | % Stmts | % Branch | % Funcs | % Lines
|
||||
---------------|---------|----------|---------|--------
|
||||
liquidity.ts | 100 | 100 | 100 | 100
|
||||
|
||||
Coverage: 100% ✅ (Hedef: 80%)
|
||||
```
|
||||
|
||||
✅ TDD oturumu tamamlandı!
|
||||
```
|
||||
|
||||
## TDD En İyi Uygulamaları
|
||||
|
||||
**YAPIN:**
|
||||
- ✅ Herhangi bir uygulamadan ÖNCE testi yazın
|
||||
- ✅ Testleri çalıştırın ve uygulamadan önce başarısız olduklarını doğrulayın
|
||||
- ✅ Testleri geçirmek için minimal kod yazın
|
||||
- ✅ Testler yeşil olduktan sonra refactor edin
|
||||
- ✅ Edge case'leri ve hata senaryolarını ekleyin
|
||||
- ✅ %80+ kapsama hedefleyin (kritik kod için %100)
|
||||
|
||||
**YAPMAYIN:**
|
||||
- ❌ Testlerden önce uygulama yazmayın
|
||||
- ❌ Her değişiklikten sonra testleri çalıştırmayı atlamayın
|
||||
- ❌ Aynı anda çok fazla kod yazmayın
|
||||
- ❌ Başarısız testleri görmezden gelmeyin
|
||||
- ❌ Uygulama detaylarını test etmeyin (davranışı test edin)
|
||||
- ❌ Her şeyi mock'lamayın (integration testleri tercih edin)
|
||||
|
||||
## Dahil Edilecek Test Türleri
|
||||
|
||||
**Unit Tests** (Fonksiyon seviyesi):
|
||||
- Happy path senaryoları
|
||||
- Edge case'ler (boş, null, maksimum değerler)
|
||||
- Hata koşulları
|
||||
- Sınır değerleri
|
||||
|
||||
**Integration Tests** (Component seviyesi):
|
||||
- API endpoint'leri
|
||||
- Database operasyonları
|
||||
- Dış servis çağrıları
|
||||
- Hook'lu React componentleri
|
||||
|
||||
**E2E Tests** (`/e2e` komutunu kullanın):
|
||||
- Kritik kullanıcı akışları
|
||||
- Çok adımlı süreçler
|
||||
- Full stack entegrasyon
|
||||
|
||||
## Kapsama Gereksinimleri
|
||||
|
||||
- **Minimum %80** tüm kod için
|
||||
- **%100 gerekli**:
|
||||
- Finansal hesaplamalar
|
||||
- Kimlik doğrulama mantığı
|
||||
- Güvenlik açısından kritik kod
|
||||
- Temel iş mantığı
|
||||
|
||||
## Önemli Notlar
|
||||
|
||||
**ZORUNLU**: Testler uygulamadan ÖNCE yazılmalıdır. TDD döngüsü:
|
||||
|
||||
1. **RED** - Başarısız test yaz
|
||||
2. **GREEN** - Geçmek için uygula
|
||||
3. **REFACTOR** - Kodu iyileştir
|
||||
|
||||
RED aşamasını asla atlamayın. Testlerden önce asla kod yazmayın.
|
||||
|
||||
## Diğer Komutlarla Entegrasyon
|
||||
|
||||
- Ne inşa edileceğini anlamak için önce `/plan` kullanın
|
||||
- Testlerle uygulamak için `/tdd` kullanın
|
||||
- Build hataları oluşursa `/build-fix` kullanın
|
||||
- Uygulamayı gözden geçirmek için `/code-review` kullanın
|
||||
- Kapsama oranını doğrulamak için `/test-coverage` kullanın
|
||||
|
||||
## İlgili Agent'lar
|
||||
|
||||
Bu komut, ECC tarafından sağlanan `tdd-guide` agent'ını çağırır.
|
||||
|
||||
İlgili `tdd-workflow` skill'i de ECC ile birlikte gelir.
|
||||
|
||||
Manuel kurulumlar için, kaynak dosyalar şurada bulunur:
|
||||
- `agents/tdd-guide.md`
|
||||
- `skills/tdd-workflow/SKILL.md`
|
||||
69
docs/tr/commands/test-coverage.md
Normal file
69
docs/tr/commands/test-coverage.md
Normal file
@@ -0,0 +1,69 @@
|
||||
# Test Coverage
|
||||
|
||||
Test coverage'ını analiz et, eksiklikleri tanımla ve 80%+ coverage'a ulaşmak için eksik test'leri oluştur.
|
||||
|
||||
## Adım 1: Test Framework'ünü Tespit Et
|
||||
|
||||
| Gösterge | Coverage Komutu |
|
||||
|-----------|-----------------|
|
||||
| `jest.config.*` veya `package.json` jest | `npx jest --coverage --coverageReporters=json-summary` |
|
||||
| `vitest.config.*` | `npx vitest run --coverage` |
|
||||
| `pytest.ini` / `pyproject.toml` pytest | `pytest --cov=src --cov-report=json` |
|
||||
| `Cargo.toml` | `cargo llvm-cov --json` |
|
||||
| `pom.xml` JaCoCo ile | `mvn test jacoco:report` |
|
||||
| `go.mod` | `go test -coverprofile=coverage.out ./...` |
|
||||
|
||||
## Adım 2: Coverage Raporunu Analiz Et
|
||||
|
||||
1. Coverage komutunu çalıştır
|
||||
2. Çıktıyı ayrıştır (JSON summary veya terminal çıktısı)
|
||||
3. **80% coverage'ın altındaki** dosyaları listele, en kötüden başlayarak sırala
|
||||
4. Her yetersiz coverage'lı dosya için şunları tanımla:
|
||||
- Test edilmemiş fonksiyonlar veya metodlar
|
||||
- Eksik branch coverage (if/else, switch, error yolları)
|
||||
- Payda'yı şişiren dead code
|
||||
|
||||
## Adım 3: Eksik Test'leri Oluştur
|
||||
|
||||
Her yetersiz coverage'lı dosya için, bu önceliği takip ederek test'ler oluştur:
|
||||
|
||||
1. **Happy path** — Geçerli input'larla temel fonksiyonalite
|
||||
2. **Hata işleme** — Geçersiz input'lar, eksik veri, network hataları
|
||||
3. **Edge case'ler** — Boş diziler, null/undefined, sınır değerleri (0, -1, MAX_INT)
|
||||
4. **Branch coverage** — Her if/else, switch case, ternary
|
||||
|
||||
### Test Oluşturma Kuralları
|
||||
|
||||
- Test'leri kaynak kodun yanına yerleştir: `foo.ts` → `foo.test.ts` (veya proje konvansiyonu)
|
||||
- Projeden mevcut test pattern'lerini kullan (import stili, assertion kütüphanesi, mocking yaklaşımı)
|
||||
- Harici bağımlılıkları mock'la (veritabanı, API'ler, dosya sistemi)
|
||||
- Her test bağımsız olmalı — test'ler arasında paylaşılan değişken state olmamalı
|
||||
- Test'leri açıklayıcı isimlendirin: `test_create_user_with_duplicate_email_returns_409`
|
||||
|
||||
## Adım 4: Doğrula
|
||||
|
||||
1. Tam test suite'ini çalıştır — tüm test'ler geçmeli
|
||||
2. Coverage'ı yeniden çalıştır — iyileşmeyi doğrula
|
||||
3. Hala 80%'in altındaysa, kalan boşluklar için Adım 3'ü tekrarla
|
||||
|
||||
## Adım 5: Raporla
|
||||
|
||||
Öncesi/sonrası karşılaştırmasını göster:
|
||||
|
||||
```
|
||||
Coverage Report
|
||||
──────────────────────────────
|
||||
File Before After
|
||||
src/services/auth.ts 45% 88%
|
||||
src/utils/validation.ts 32% 82%
|
||||
──────────────────────────────
|
||||
Overall: 67% 84% ✅
|
||||
```
|
||||
|
||||
## Odak Alanları
|
||||
|
||||
- Karmaşık branching'e sahip fonksiyonlar (yüksek cyclomatic complexity)
|
||||
- Hata işleyiciler ve catch blokları
|
||||
- Codebase genelinde kullanılan utility fonksiyonları
|
||||
- API endpoint handler'ları (request → response akışı)
|
||||
- Edge case'ler: null, undefined, empty string, empty array, zero, negatif sayılar
|
||||
84
docs/tr/commands/update-docs.md
Normal file
84
docs/tr/commands/update-docs.md
Normal file
@@ -0,0 +1,84 @@
|
||||
# Update Documentation
|
||||
|
||||
Dokümanları codebase ile senkronize et, truth-of-source dosyalarından oluştur.
|
||||
|
||||
## Adım 1: Truth Kaynaklarını Tanımla
|
||||
|
||||
| Kaynak | Oluşturur |
|
||||
|--------|-----------|
|
||||
| `package.json` scripts | Mevcut komutlar referansı |
|
||||
| `.env.example` | Environment variable dokümanı |
|
||||
| `openapi.yaml` / route dosyaları | API endpoint referansı |
|
||||
| Kaynak kod export'ları | Public API dokümanı |
|
||||
| `Dockerfile` / `docker-compose.yml` | Altyapı kurulum dokümanları |
|
||||
|
||||
## Adım 2: Script Referansı Oluştur
|
||||
|
||||
1. `package.json`'ı oku (veya `Makefile`, `Cargo.toml`, `pyproject.toml`)
|
||||
2. Tüm script'leri/komutları açıklamalarıyla birlikte çıkar
|
||||
3. Bir referans tablosu oluştur:
|
||||
|
||||
```markdown
|
||||
| Command | Description |
|
||||
|---------|-------------|
|
||||
| `npm run dev` | Hot reload ile development server'ı başlat |
|
||||
| `npm run build` | Type checking ile production build |
|
||||
| `npm test` | Coverage ile test suite'ini çalıştır |
|
||||
```
|
||||
|
||||
## Adım 3: Environment Dokümanı Oluştur
|
||||
|
||||
1. `.env.example`'ı oku (veya `.env.template`, `.env.sample`)
|
||||
2. Tüm değişkenleri amaçlarıyla birlikte çıkar
|
||||
3. Zorunlu vs isteğe bağlı olarak kategorize et
|
||||
4. Beklenen format ve geçerli değerleri dokümante et
|
||||
|
||||
```markdown
|
||||
| Variable | Required | Description | Example |
|
||||
|----------|----------|-------------|---------|
|
||||
| `DATABASE_URL` | Yes | PostgreSQL bağlantı string'i | `postgres://user:pass@host:5432/db` |
|
||||
| `LOG_LEVEL` | No | Log detay seviyesi (varsayılan: info) | `debug`, `info`, `warn`, `error` |
|
||||
```
|
||||
|
||||
## Adım 4: Contributing Guide'ı Güncelle
|
||||
|
||||
`docs/CONTRIBUTING.md`'yi şunlarla oluştur veya güncelle:
|
||||
- Development environment kurulumu (ön koşullar, kurulum adımları)
|
||||
- Mevcut script'ler ve amaçları
|
||||
- Test prosedürleri (nasıl çalıştırılır, nasıl yeni test yazılır)
|
||||
- Kod stili zorlama (linter, formatter, pre-commit hook'ları)
|
||||
- PR gönderim kontrol listesi
|
||||
|
||||
## Adım 5: Runbook'u Güncelle
|
||||
|
||||
`docs/RUNBOOK.md`'yi şunlarla oluştur veya güncelle:
|
||||
- Deployment prosedürleri (adım adım)
|
||||
- Health check endpoint'leri ve izleme
|
||||
- Yaygın sorunlar ve düzeltmeleri
|
||||
- Rollback prosedürleri
|
||||
- Uyarı ve eskalasyon yolları
|
||||
|
||||
## Adım 6: Güncellik Kontrolü
|
||||
|
||||
1. 90+ gün değiştirilmemiş doküman dosyalarını bul
|
||||
2. Son kaynak kod değişiklikleriyle çapraz referans yap
|
||||
3. Manuel gözden geçirme için potansiyel güncel olmayan dokümanları işaretle
|
||||
|
||||
## Adım 7: Özeti Göster
|
||||
|
||||
```
|
||||
Documentation Update
|
||||
──────────────────────────────
|
||||
Updated: docs/CONTRIBUTING.md (scripts table)
|
||||
Updated: docs/ENV.md (3 new variables)
|
||||
Flagged: docs/DEPLOY.md (142 days stale)
|
||||
Skipped: docs/API.md (no changes detected)
|
||||
──────────────────────────────
|
||||
```
|
||||
|
||||
## Kurallar
|
||||
|
||||
- **Tek truth kaynağı**: Her zaman koddan oluştur, oluşturulan bölümleri asla manuel düzenleme
|
||||
- **Manuel bölümleri koru**: Sadece oluşturulan bölümleri güncelle; elle yazılmış prose'u bozulmamış bırak
|
||||
- **Oluşturulan içeriği işaretle**: Oluşturulan bölümlerin etrafında `<!-- AUTO-GENERATED -->` marker'ları kullan
|
||||
- **İstenmeyen doküman oluşturma**: Sadece komut açıkça talep ederse yeni doküman dosyaları oluştur
|
||||
59
docs/tr/commands/verify.md
Normal file
59
docs/tr/commands/verify.md
Normal file
@@ -0,0 +1,59 @@
|
||||
# Verification Komutu
|
||||
|
||||
Mevcut kod tabanı durumu üzerinde kapsamlı doğrulama çalıştır.
|
||||
|
||||
## Talimatlar
|
||||
|
||||
Doğrulamayı tam olarak bu sırayla yürüt:
|
||||
|
||||
1. **Build Kontrolü**
|
||||
- Bu proje için build komutunu çalıştır
|
||||
- Başarısız olursa, hataları raporla ve DUR
|
||||
|
||||
2. **Tip Kontrolü**
|
||||
- TypeScript/tip denetleyicisini çalıştır
|
||||
- Tüm hataları dosya:satır ile raporla
|
||||
|
||||
3. **Lint Kontrolü**
|
||||
- Linter'ı çalıştır
|
||||
- Uyarıları ve hataları raporla
|
||||
|
||||
4. **Test Paketi**
|
||||
- Tüm testleri çalıştır
|
||||
- Geçti/başarısız sayısını raporla
|
||||
- Kapsama yüzdesini raporla
|
||||
|
||||
5. **Console.log Denetimi**
|
||||
- Kaynak dosyalarda console.log ara
|
||||
- Konumları raporla
|
||||
|
||||
6. **Git Durumu**
|
||||
- Commit edilmemiş değişiklikleri göster
|
||||
- Son commit'ten beri değiştirilen dosyaları göster
|
||||
|
||||
## Çıktı
|
||||
|
||||
Özet bir doğrulama raporu üret:
|
||||
|
||||
```
|
||||
DOĞRULAMA: [GEÇTİ/BAŞARISIZ]
|
||||
|
||||
Build: [TAMAM/BAŞARISIZ]
|
||||
Tipler: [TAMAM/X hata]
|
||||
Lint: [TAMAM/X sorun]
|
||||
Testler: [X/Y geçti, Z% kapsama]
|
||||
Gizli: [TAMAM/X bulundu]
|
||||
Loglar: [TAMAM/X console.log]
|
||||
|
||||
PR için Hazır: [EVET/HAYIR]
|
||||
```
|
||||
|
||||
Herhangi bir kritik sorun varsa, düzeltme önerileriyle listele.
|
||||
|
||||
## Argümanlar
|
||||
|
||||
$ARGUMENTS şunlar olabilir:
|
||||
- `quick` - Sadece build + tipler
|
||||
- `full` - Tüm kontroller (varsayılan)
|
||||
- `pre-commit` - Commit'ler için ilgili kontroller
|
||||
- `pre-pr` - Güvenlik taraması artı tam kontroller
|
||||
Reference in New Issue
Block a user