mirror of
https://github.com/affaan-m/ECC.git
synced 2026-09-18 15:50:25 +02:00
928c1dea72
* feat: bundle standalone taste distillation and application workflows * docs: fix imported taste skill markdown lint * docs: align Turkish agent catalog with taste skills * refactor: make ECC the canonical reusable video engine * fix: preserve video duration when applying image overlays * fix: preserve background colors in image compositing * fix: report best-effort duration targets and shortfalls * feat: ship verified Fusion presets with compatibility provenance * feat(tasteforge): preserve native edits in application bundles * feat(tasteforge): compile local preservation without hosted input * fix: update js-yaml to patched 4.3.2 * test: report bounded Stop wrapper failure diagnostics * fix(tasteforge): fail closed on unsafe output names, missing overlays and cadence - cli: default report and spec paths are derived from pack name and profile genre; require the manifest's name pattern before using either as a filename part so a traversal string cannot write outside cwd/out. - apply_local: a pack without cadence.json, or with no measured shots and no explicit mean_shot, raises instead of silently planning 1.0s shots and reporting a measured cadence. - legacy apply: a missing overlay aborts before any paid upload; forge() would have rejected it after every take was generated. - requirements-live: pin fal-client>=0.13.0, the first release whose subscribe() accepts client_timeout. Addresses the five P1 findings from the independent review of #3033. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015fxHRsydPqEcYngGbqkgt1 --------- Co-authored-by: Claude Fable 5.1 <noreply@anthropic.com>
161 lines
8.9 KiB
Markdown
161 lines
8.9 KiB
Markdown
# Everything Claude Code (ECC) — Agent Talimatları
|
||
|
||
Bu, yazılım geliştirme için 68 özel agent, 291 skill, 94 command ve otomatik hook iş akışları sağlayan **üretime hazır bir AI kodlama eklentisidir**.
|
||
|
||
**Sürüm:** 2.2.1
|
||
|
||
## Temel İlkeler
|
||
|
||
1. **Agent-Öncelikli** — Alan görevleri için özel agentlara delege edin
|
||
2. **Test-Odaklı** — Uygulamadan önce testler yazın, %80+ kapsama gereklidir
|
||
3. **Güvenlik-Öncelikli** — Güvenlikten asla taviz vermeyin; tüm girdileri doğrulayın
|
||
4. **Değişmezlik** — Her zaman yeni nesneler oluşturun, mevcut olanları asla değiştirmeyin
|
||
5. **Çalıştırmadan Önce Planlayın** — Karmaşık özellikleri kod yazmadan önce planlayın
|
||
|
||
## Mevcut Agentlar
|
||
|
||
| Agent | Amaç | Ne Zaman Kullanılır |
|
||
|-------|---------|-------------|
|
||
| planner | Uygulama planlaması | Karmaşık özellikler, yeniden düzenleme |
|
||
| architect | Sistem tasarımı ve ölçeklenebilirlik | Mimari kararlar |
|
||
| tdd-guide | Test-odaklı geliştirme | Yeni özellikler, hata düzeltmeleri |
|
||
| code-reviewer | Kod kalitesi ve sürdürülebilirlik | Kod yazma/değiştirme sonrası |
|
||
| security-reviewer | Güvenlik açığı tespiti | Commitlerden önce, hassas kod |
|
||
| build-error-resolver | Build/tip hatalarını düzeltme | Build başarısız olduğunda |
|
||
| e2e-runner | Uçtan uca Playwright testi | Kritik kullanıcı akışları |
|
||
| refactor-cleaner | Ölü kod temizleme | Kod bakımı |
|
||
| doc-updater | Dokümantasyon ve codemaps | Dokümanları güncelleme |
|
||
| docs-lookup | Dokümantasyon ve API referans araştırması | Kütüphane/API dokümantasyon soruları |
|
||
| cpp-reviewer | C++ kod incelemesi | C++ projeleri |
|
||
| cpp-build-resolver | C++ build hataları | C++ build başarısızlıkları |
|
||
| go-reviewer | Go kod incelemesi | Go projeleri |
|
||
| go-build-resolver | Go build hataları | Go build başarısızlıkları |
|
||
| kotlin-reviewer | Kotlin kod incelemesi | Kotlin/Android/KMP projeleri |
|
||
| kotlin-build-resolver | Kotlin/Gradle build hataları | Kotlin build başarısızlıkları |
|
||
| database-reviewer | PostgreSQL/Supabase uzmanı | Şema tasarımı, sorgu optimizasyonu |
|
||
| python-reviewer | Python kod incelemesi | Python projeleri |
|
||
| java-reviewer | Java ve Spring Boot kod incelemesi | Java/Spring Boot projeleri |
|
||
| java-build-resolver | Java/Maven/Gradle build hataları | Java build başarısızlıkları |
|
||
| chief-of-staff | İletişim önceliklendirme ve taslaklar | Çok kanallı email, Slack, LINE, Messenger |
|
||
| loop-operator | Otonom döngü yürütme | Döngüleri güvenli çalıştırma, takılmaları izleme, müdahale |
|
||
| harness-optimizer | Harness yapılandırma ayarlama | Güvenilirlik, maliyet, verimlilik |
|
||
| rust-reviewer | Rust kod incelemesi | Rust projeleri |
|
||
| rust-build-resolver | Rust build hataları | Rust build başarısızlıkları |
|
||
| pytorch-build-resolver | PyTorch runtime/CUDA/eğitim hataları | PyTorch build/eğitim başarısızlıkları |
|
||
| typescript-reviewer | TypeScript/JavaScript kod incelemesi | TypeScript/JavaScript projeleri |
|
||
|
||
## Agent Orkestrasyonu
|
||
|
||
Agentları kullanıcı istemi olmadan proaktif olarak kullanın:
|
||
- Karmaşık özellik istekleri → **planner**
|
||
- Yeni yazılan/değiştirilen kod → **code-reviewer**
|
||
- Hata düzeltme veya yeni özellik → **tdd-guide**
|
||
- Mimari karar → **architect**
|
||
- Güvenlik açısından hassas kod → **security-reviewer**
|
||
- Çok kanallı iletişim önceliklendirme → **chief-of-staff**
|
||
- Otonom döngüler / döngü izleme → **loop-operator**
|
||
- Harness yapılandırma güvenilirliği ve maliyeti → **harness-optimizer**
|
||
|
||
Bağımsız işlemler için paralel yürütme kullanın — birden fazla agenti aynı anda başlatın.
|
||
|
||
## Güvenlik Kuralları
|
||
|
||
**HERHANGİ BİR committen önce:**
|
||
- Sabit kodlanmış sırlar yok (API anahtarları, şifreler, tokenlar)
|
||
- Tüm kullanıcı girdileri doğrulanmış
|
||
- SQL injection koruması (parametreli sorgular)
|
||
- XSS koruması (sanitize edilmiş HTML)
|
||
- CSRF koruması etkin
|
||
- Kimlik doğrulama/yetkilendirme doğrulanmış
|
||
- Tüm endpointlerde hız sınırlama
|
||
- Hata mesajları hassas veri sızdırmıyor
|
||
|
||
**Sır yönetimi:** Sırları asla sabit kodlamayın. Ortam değişkenlerini veya bir sır yöneticisini kullanın. Başlangıçta gerekli sırları doğrulayın. İfşa edilen sırları hemen döndürün.
|
||
|
||
**Güvenlik sorunu bulunursa:** DUR → security-reviewer agentini kullan → KRİTİK sorunları düzelt → ifşa edilen sırları döndür → kod tabanını benzer sorunlar için incele.
|
||
|
||
## Kodlama Stili
|
||
|
||
**Değişmezlik (KRİTİK):** Her zaman yeni nesneler oluşturun, asla değiştirmeyin. Değişiklikler uygulanmış yeni kopyalar döndürün.
|
||
|
||
**Dosya organizasyonu:** Az sayıda büyük dosya yerine çok sayıda küçük dosya. Tipik 200-400 satır, maksimum 800. Tipe göre değil, özelliğe/alana göre düzenleyin. Yüksek bağlılık, düşük bağımlılık.
|
||
|
||
**Hata yönetimi:** Her seviyede hataları ele alın. UI kodunda kullanıcı dostu mesajlar sağlayın. Sunucu tarafında detaylı bağlamı loglayın. Hataları asla sessizce yutmayın.
|
||
|
||
**Girdi doğrulama:** Sistem sınırlarında tüm kullanıcı girdilerini doğrulayın. Şema tabanlı doğrulama kullanın. Net mesajlarla hızlı başarısız olun. Harici verilere asla güvenmeyin.
|
||
|
||
**Kod kalite kontrol listesi:**
|
||
- Fonksiyonlar küçük (<50 satır), dosyalar odaklı (<800 satır)
|
||
- Derin iç içe geçme yok (>4 seviye)
|
||
- Düzgün hata yönetimi, sabit kodlanmış değerler yok
|
||
- Okunabilir, iyi adlandırılmış tanımlayıcılar
|
||
|
||
## Test Gereksinimleri
|
||
|
||
**Minimum kapsama: %80**
|
||
|
||
Test tipleri (hepsi gereklidir):
|
||
1. **Unit testler** — Bireysel fonksiyonlar, yardımcı programlar, bileşenler
|
||
2. **Integration testler** — API endpointleri, veritabanı işlemleri
|
||
3. **E2E testler** — Kritik kullanıcı akışları
|
||
|
||
**TDD iş akışı (zorunlu):**
|
||
1. Önce test yaz (KIRMIZI) — test BAŞARISIZ olmalı
|
||
2. Minimal uygulama yaz (YEŞİL) — test BAŞARILI olmalı
|
||
3. Yeniden düzenle (İYİLEŞTİR) — %80+ kapsama doğrula
|
||
|
||
Başarısızlık sorunlarını giderin: test izolasyonunu kontrol edin → mocklarını doğrulayın → uygulamayı düzeltin (testleri değil, testler yanlış olmadıkça).
|
||
|
||
## Geliştirme İş Akışı
|
||
|
||
1. **Planlama** — Planner agentini kullanın, bağımlılıkları ve riskleri belirleyin, aşamalara bölün
|
||
2. **TDD** — tdd-guide agentini kullanın, önce testleri yazın, uygulayın, yeniden düzenleyin
|
||
3. **İnceleme** — code-reviewer agentini hemen kullanın, KRİTİK/YÜKSEK sorunları ele alın
|
||
4. **Bilgiyi doğru yerde yakalayın**
|
||
- Kişisel hata ayıklama notları, tercihler ve geçici bağlam → otomatik bellek
|
||
- Takım/proje bilgisi (mimari kararlar, API değişiklikleri, runbook'lar) → projenin mevcut doküman yapısı
|
||
- Mevcut görev zaten ilgili dokümanları veya kod yorumlarını üretiyorsa, aynı bilgiyi başka yerde çoğaltmayın
|
||
- Açık bir proje doküman konumu yoksa, yeni bir üst düzey dosya oluşturmadan önce sorun
|
||
5. **Commit** — Conventional commits formatı, kapsamlı PR özetleri
|
||
|
||
## Git İş Akışı
|
||
|
||
**Commit formatı:** `<type>: <description>` — Tipler: feat, fix, refactor, docs, test, chore, perf, ci
|
||
|
||
**PR iş akışı:** Tam commit geçmişini analiz edin → kapsamlı özet taslağı oluşturun → test planı ekleyin → `-u` bayrağıyla pushlayın.
|
||
|
||
## Mimari Desenler
|
||
|
||
**API yanıt formatı:** Başarı göstergesi, veri yükü, hata mesajı ve sayfalandırma metadatası içeren tutarlı zarf.
|
||
|
||
**Repository deseni:** Veri erişimini standart arayüz arkasında kapsülleyin (findAll, findById, create, update, delete). İş mantığı depolama mekanizmasına değil, soyut arayüze bağlıdır.
|
||
|
||
**Skeleton projeleri:** Savaş testinden geçmiş şablonları arayın, paralel agentlarla değerlendirin (güvenlik, genişletilebilirlik, uygunluk), en iyi eşleşmeyi klonlayın, kanıtlanmış yapı içinde yineleyin.
|
||
|
||
## Performans
|
||
|
||
**Bağlam yönetimi:** Büyük yeniden düzenlemeler ve çok dosyalı özellikler için bağlam penceresinin son %20'sinden kaçının. Daha düşük hassasiyet gerektiren görevler (tekli düzenlemeler, dokümanlar, basit düzeltmeler) daha yüksek kullanımı tolere eder.
|
||
|
||
**Build sorun giderme:** build-error-resolver agentini kullanın → hataları analiz edin → artımlı olarak düzeltin → her düzeltmeden sonra doğrulayın.
|
||
|
||
## Proje Yapısı
|
||
|
||
```
|
||
agents/ — 68 özel subagent
|
||
skills/ — 291 iş akışı skillleri ve alan bilgisi
|
||
commands/ — 94 slash command
|
||
hooks/ — Tetikleyici tabanlı otomasyonlar
|
||
rules/ — Her zaman uyulması gereken kurallar (ortak + dile özel)
|
||
scripts/ — Platformlar arası Node.js yardımcı programları
|
||
mcp-configs/ — 14 MCP sunucu yapılandırması
|
||
tests/ — Test paketi
|
||
```
|
||
|
||
## Başarı Metrikleri
|
||
|
||
- Tüm testler %80+ kapsama ile geçer
|
||
- Güvenlik açığı yoktur
|
||
- Kod okunabilir ve sürdürülebilirdir
|
||
- Performans kabul edilebilirdir
|
||
- Kullanıcı gereksinimleri karşılanmıştır
|