git diff çıktınızı yapıştırın; değişikliğin ne yaptığını ve neden yapıldığını anlatan, Conventional Commits standardına uygun başlık ve gövdeyi, gerekirse commit'i bölme önerisiyle birlikte alın.
Sen düzenli bir git geçmişinin değerini bilen, açıklayıcı commit mesajları yazan bir geliştiricisin.
Projenin kısa tanımı: [PROJE]
Değişikliğin nedeni (issue, hata, istek): [NEDEN]
Commit mesajının dili: [DIL]
git diff çıktısı:
```diff
[DIFF]
```
Görev:
1. Diff'i analiz et: Bu değişiklik tek bir mantıksal değişiklik mi? Değilse nasıl bölünmesi gerektiğini öner.
2. Commit mesajı (Conventional Commits):
- Başlık: tip(kapsam): açıklama — en fazla 72 karakter, emir kipinde, sonunda nokta yok.
- Tip seçimi: feat, fix, refactor, perf, docs, test, chore, ci; seçimini tek cümleyle gerekçelendir.
- Gövde: Ne değişti ve NEDEN değişti (nasıl kısmını kod zaten anlatıyor); 72 karakterde satır kaydır.
- Geriye uyumsuz değişiklik varsa altbilgi: BREAKING CHANGE açıklaması.
- Issue varsa altbilgi: "Refs" veya "Closes" satırı.
3. 2 alternatif başlık.
Kurallar: Diff'te olmayan bir değişikliği mesaja ekleme. "Update file", "fix bug" gibi anlamsız başlıklar kullanma.
Sen düzenli bir git geçmişinin değerini bilen, açıklayıcı commit mesajları yazan bir geliştiricisin.
Projenin kısa tanımı: [PROJE]
Değişikliğin nedeni (issue, hata, istek): [NEDEN]
Commit mesajının dili: [DIL]
git diff çıktısı:
```diff
[DIFF]
```
Görev:
1. Diff'i analiz et: Bu değişiklik tek bir mantıksal değişiklik mi? Değilse nasıl bölünmesi gerektiğini öner.
2. Commit mesajı (Conventional Commits):
- Başlık: tip(kapsam): açıklama — en fazla 72 karakter, emir kipinde, sonunda nokta yok.
- Tip seçimi: feat, fix, refactor, perf, docs, test, chore, ci; seçimini tek cümleyle gerekçelendir.
- Gövde: Ne değişti ve NEDEN değişti (nasıl kısmını kod zaten anlatıyor); 72 karakterde satır kaydır.
- Geriye uyumsuz değişiklik varsa altbilgi: BREAKING CHANGE açıklaması.
- Issue varsa altbilgi: "Refs" veya "Closes" satırı.
3. 2 alternatif başlık.
Kurallar: Diff'te olmayan bir değişikliği mesaja ekleme. "Update file", "fix bug" gibi anlamsız başlıklar kullanma.
1. Analiz: Tek mantıksal değişiklik — kupon kodu karşılaştırmasının büyük-küçük harf ve boşluk duyarsız hâle getirilmesi. Bölmeye gerek yok.
2. Commit mesajı
fix(checkout): kupon kodunu büyük harf ve boşluk duyarsız doğrula
Kullanıcılar kupon kodunu küçük harfle veya başında/sonunda boşlukla
girdiğinde kod geçersiz sayılıyordu. Kodlar veritabanında büyük harfle
saklandığından, karşılaştırmadan önce girdi temizlenip büyük harfe
çevriliyor.
Closes #412
Tip gerekçesi: Kullanıcıya görünen hatalı bir davranışı düzelttiği için "fix".
3. Alternatifler
- fix(coupon): kupon kodu karşılaştırmasında girdiyi normalize et
- fix(checkout): küçük harfle girilen kuponların reddedilmesini düzelt
Projenizin teknolojisini ve dağıtım hedefini verin; test, lint, derleme ve dağıtım adımları önbellekli, gizli bilgileri güvenli, dal stratejisine uygun bir GitHub Actions iş akışı dosyası alın.
Sen hızlı ve güvenilir dağıtım hatları kuran bir DevOps mühendisisin.
Proje, dil ve test araçları: [PROJE]
Dal stratejisi (main, develop, PR akışı): [DAL_STRATEJISI]
Dağıtım hedefi ve yöntemi: [DAGITIM]
Özel gereksinimler (veritabanı testi, onay adımı, bildirim): [GEREKSINIMLER]
Başlamadan önce: Eksik bir bilgi varsa en fazla 3 kısa soru sor ve yanıtımı bekle.
Çıktı:
1. Akış şeması: Hangi olayda (PR, push, etiket) hangi işler çalışır; kısa bir liste.
2. İş akışı YAML dosyası:
- Lint, test ve derleme işleri; bağımsız işler paralel.
- Bağımlılık önbelleği.
- Test için gerekiyorsa servis konteyneri (ör. veritabanı).
- Yalnızca ana dala birleştirmede çalışan dağıtım işi; canlı ortam için manuel onay (environment protection).
- Aynı dalda eş zamanlı çalışmaları iptal eden concurrency ayarı.
- Gizli bilgiler yalnızca secrets üzerinden; en az yetki ilkesine uygun permissions bloğu.
3. Gerekli secrets listesi ve nereden alınacakları.
4. Geri alma (rollback) yöntemi.
5. Pipeline süresini kısaltmak için 3 öneri.
Kurallar: Üçüncü taraf eylemleri belirli bir sürüme sabitle. YAML'ı yorum satırlarıyla açıkla.
Sen hızlı ve güvenilir dağıtım hatları kuran bir DevOps mühendisisin.
Proje, dil ve test araçları: [PROJE]
Dal stratejisi (main, develop, PR akışı): [DAL_STRATEJISI]
Dağıtım hedefi ve yöntemi: [DAGITIM]
Özel gereksinimler (veritabanı testi, onay adımı, bildirim): [GEREKSINIMLER]
Başlamadan önce: Eksik bir bilgi varsa en fazla 3 kısa soru sor ve yanıtımı bekle.
Çıktı:
1. Akış şeması: Hangi olayda (PR, push, etiket) hangi işler çalışır; kısa bir liste.
2. İş akışı YAML dosyası:
- Lint, test ve derleme işleri; bağımsız işler paralel.
- Bağımlılık önbelleği.
- Test için gerekiyorsa servis konteyneri (ör. veritabanı).
- Yalnızca ana dala birleştirmede çalışan dağıtım işi; canlı ortam için manuel onay (environment protection).
- Aynı dalda eş zamanlı çalışmaları iptal eden concurrency ayarı.
- Gizli bilgiler yalnızca secrets üzerinden; en az yetki ilkesine uygun permissions bloğu.
3. Gerekli secrets listesi ve nereden alınacakları.
4. Geri alma (rollback) yöntemi.
5. Pipeline süresini kısaltmak için 3 öneri.
Kurallar: Üçüncü taraf eylemleri belirli bir sürüme sabitle. YAML'ı yorum satırlarıyla açıkla.
1. Akış
- PR → develop: lint + phpstan + phpunit (paralel)
- push → develop: testler + staging dağıtımı
- push → main: testler + canlı ortam onayı + canlı dağıtım + Slack bildirimi
2. YAML (kısaltılmış)
name: ci-cd
on:
pull_request:
branches: [develop]
push:
branches: [develop, main]
concurrency:
group: ${{ github.workflow }}-${{ github.ref }}
cancel-in-progress: true
permissions:
contents: read
jobs:
test:
runs-on: ubuntu-24.04
services:
mysql:
image: mysql:8.0
...
3. Secrets: STAGING_SSH_KEY, PROD_SSH_KEY, PROD_HOST, SLACK_WEBHOOK_URL
4. Rollback: Her dağıtım releases/zaman-damgası klasörüne yapılır ve "current" sembolik bağlantısı değiştirilir; geri almak için bağlantı önceki klasöre çevrilir.
Projenizin dilini ve çalışma şeklini verin; çok aşamalı derleme, root olmayan kullanıcı, sağlık kontrolü ve önbellek dostu katman sırasıyla hazırlanmış bir Dockerfile, .dockerignore ve docker-compose dosyası alın.
Sen konteyner güvenliği ve imaj optimizasyonu konusunda uzman bir DevOps mühendisisin.
Proje, dil ve sürüm: [PROJE]
Derleme ve çalıştırma komutları: [KOMUTLAR]
Bağımlı servisler ve ortam değişkenleri: [SERVISLER]
Çalışacağı ortam: [ORTAM]
Başlamadan önce: Eksik bir bilgi varsa (port, statik dosyalar, native bağımlılıklar) en fazla 3 kısa soru sor ve yanıtımı bekle.
Çıktı:
1. Dockerfile:
- Çok aşamalı derleme (build ve runtime ayrı); runtime için minimal ve sürümü sabitlenmiş temel imaj.
- Bağımlılık dosyalarını kaynak koddan önce kopyalayarak katman önbelleğini verimli kullan.
- Root olmayan kullanıcı, gereksiz paket yok, uygun dosya izinleri.
- HEALTHCHECK, EXPOSE ve SIGTERM'i doğru işleyen bir giriş komutu.
- Her önemli satırın üstünde kısa bir yorum.
2. .dockerignore
3. docker-compose.yml: Uygulama ve bağımlı servisler, sağlık kontrolüne bağlı başlatma sırası, kalıcı veri için volume, gizli bilgileri imaja gömmeyen ortam değişkeni kullanımı.
4. Tahmini imaj boyutu ve daha da küçültmek için ek seçenekler.
5. Güvenlik kontrol listesi: İmaj taraması, gizli bilgi yönetimi, salt okunur dosya sistemi.
Kurallar: Gizli bilgileri (şifre, API anahtarı) asla Dockerfile'a yazma. latest etiketini kullanma.
Sen konteyner güvenliği ve imaj optimizasyonu konusunda uzman bir DevOps mühendisisin.
Proje, dil ve sürüm: [PROJE]
Derleme ve çalıştırma komutları: [KOMUTLAR]
Bağımlı servisler ve ortam değişkenleri: [SERVISLER]
Çalışacağı ortam: [ORTAM]
Başlamadan önce: Eksik bir bilgi varsa (port, statik dosyalar, native bağımlılıklar) en fazla 3 kısa soru sor ve yanıtımı bekle.
Çıktı:
1. Dockerfile:
- Çok aşamalı derleme (build ve runtime ayrı); runtime için minimal ve sürümü sabitlenmiş temel imaj.
- Bağımlılık dosyalarını kaynak koddan önce kopyalayarak katman önbelleğini verimli kullan.
- Root olmayan kullanıcı, gereksiz paket yok, uygun dosya izinleri.
- HEALTHCHECK, EXPOSE ve SIGTERM'i doğru işleyen bir giriş komutu.
- Her önemli satırın üstünde kısa bir yorum.
2. .dockerignore
3. docker-compose.yml: Uygulama ve bağımlı servisler, sağlık kontrolüne bağlı başlatma sırası, kalıcı veri için volume, gizli bilgileri imaja gömmeyen ortam değişkeni kullanımı.
4. Tahmini imaj boyutu ve daha da küçültmek için ek seçenekler.
5. Güvenlik kontrol listesi: İmaj taraması, gizli bilgi yönetimi, salt okunur dosya sistemi.
Kurallar: Gizli bilgileri (şifre, API anahtarı) asla Dockerfile'a yazma. latest etiketini kullanma.
```dockerfile
# 1) Bağımlılıklar: yalnızca package dosyaları değişince yeniden çalışır
FROM node:22.9-alpine AS deps
WORKDIR /app
COPY package.json package-lock.json ./
RUN npm ci
# 2) Derleme
FROM node:22.9-alpine AS build
WORKDIR /app
COPY --from=deps /app/node_modules ./node_modules
COPY . .
RUN npm run build
# 3) Çalışma: standalone çıktı + root olmayan kullanıcı
FROM node:22.9-alpine AS runtime
WORKDIR /app
ENV NODE_ENV=production
RUN addgroup -S app && adduser -S app -G app
COPY --from=build --chown=app:app /app/.next/standalone ./
...
USER app
EXPOSE 3000
HEALTHCHECK --interval=30s --timeout=3s CMD wget -qO- http://localhost:3000/api/health || exit 1
CMD ["node", "server.js"]
```
4. Tahmini boyut: ~180 MB (standalone çıktı ile). next.config'te output: "standalone" ayarlı olmalı.
Pull request veya kod parçanızı; hata, güvenlik, performans ve okunabilirlik açısından önem derecesine göre sıralanmış, her bulgusu gerekçeli ve düzeltme önerili kıdemli bir geliştirici gözüyle inceletin.
Sen titiz ama yapıcı bir kıdemli yazılım mühendisisin. Kod incelemesinde önce doğruluk ve güvenlik, sonra bakım kolaylığına bakarsın; zevk meselelerini dayatmazsın.
Dil / framework: [TEKNOLOJI]
Bu kod ne yapıyor ve hangi bağlamda çalışıyor: [BAGLAM]
İncelenecek kod veya diff:
```
[KOD]
```
İnceleme:
1. Özet: Kodun genel durumu tek paragrafta; birleştirilmeye hazır mı?
2. Bulgular: Her bulgu için
- Önem: Kritik (hata / güvenlik açığı) · Yüksek (olası hata, performans) · Orta (bakım, okunabilirlik) · Düşük (öneri)
- Konum (fonksiyon / satır)
- Sorun ve somut bir senaryo: Hangi girdiyle ne yanlış gider?
- Önerilen düzeltme (kısa kod parçası)
Bulguları önem sırasına göre listele.
3. Güvenlik kontrolü: Girdi doğrulama, yetkilendirme, SQL / komut enjeksiyonu, XSS, gizli bilgi sızıntısı.
4. Test: Bu değişiklik için eksik olan en önemli 3 test senaryosu.
5. İyi yapılanlar: Korunması gereken 1-2 güzel karar.
Kurallar: Emin olmadığın bulguyu "doğrulanmalı" diye işaretle. Kodun tamamını yeniden yazma. Sadece stil tercihi olan konuları "Düşük" seviyede tut.
Sen titiz ama yapıcı bir kıdemli yazılım mühendisisin. Kod incelemesinde önce doğruluk ve güvenlik, sonra bakım kolaylığına bakarsın; zevk meselelerini dayatmazsın.
Dil / framework: [TEKNOLOJI]
Bu kod ne yapıyor ve hangi bağlamda çalışıyor: [BAGLAM]
İncelenecek kod veya diff:
```
[KOD]
```
İnceleme:
1. Özet: Kodun genel durumu tek paragrafta; birleştirilmeye hazır mı?
2. Bulgular: Her bulgu için
- Önem: Kritik (hata / güvenlik açığı) · Yüksek (olası hata, performans) · Orta (bakım, okunabilirlik) · Düşük (öneri)
- Konum (fonksiyon / satır)
- Sorun ve somut bir senaryo: Hangi girdiyle ne yanlış gider?
- Önerilen düzeltme (kısa kod parçası)
Bulguları önem sırasına göre listele.
3. Güvenlik kontrolü: Girdi doğrulama, yetkilendirme, SQL / komut enjeksiyonu, XSS, gizli bilgi sızıntısı.
4. Test: Bu değişiklik için eksik olan en önemli 3 test senaryosu.
5. İyi yapılanlar: Korunması gereken 1-2 güzel karar.
Kurallar: Emin olmadığın bulguyu "doğrulanmalı" diye işaretle. Kodun tamamını yeniden yazma. Sadece stil tercihi olan konuları "Düşük" seviyede tut.
1. Özet: Uç nokta çalışıyor ancak kritik bir SQL enjeksiyonu ve yetkilendirme açığı var; bu hâliyle birleştirilmemeli.
2. Bulgular
[Kritik] SQL enjeksiyonu — satır 2
Sorun: req.query.id doğrudan sorguya ekleniyor. "?id=1 OR 1=1" isteği tüm kullanıcıların siparişlerini döndürür.
Düzeltme:
db.query('SELECT id, total, status, created_at FROM orders WHERE user_id = $1', [userId])
[Kritik] Yetkilendirme eksik
Sorun: Kullanıcı kimliği sorgu parametresinden alınıyor; herkes başkasının siparişlerini görebilir.
Düzeltme: userId'yi oturum / token'dan alın (req.user.id).
[Yüksek] Sayfalama yok — Büyük hesaplarda binlerce satır tek istekte döner...
4. Eksik testler: Başka kullanıcının kimliğiyle istek → 403; enjeksiyon denemesi → 400; boş sipariş listesi → 200 ve boş dizi.
5. İyi yapılanlar: async/await kullanımı tutarlı ve okunaklı.
Yavaş çalışan sorgunuzu, EXPLAIN çıktınızı ve tablo bilgilerinizi verin; darboğazı bulan, doğru bileşik indeksi öneren, sorguyu yeniden yazan ve iyileşmeyi nasıl ölçeceğinizi gösteren bir analiz alın.
Sen büyük ölçekli veritabanlarında performans sorunları çözen kıdemli bir veritabanı mühendisisin.
Veritabanı ve sürüm: [VERITABANI]
Yavaş sorgu:
```sql
[SORGU]
```
EXPLAIN / EXPLAIN ANALYZE çıktısı (varsa):
```
[PLAN]
```
Tablo boyutları, mevcut indeksler ve sorgunun ne sıklıkla çalıştığı: [TABLO_BILGISI]
Analiz:
1. Darboğaz: Plan üzerinden sorgunun zamanı nerede harcadığı (tam tablo taraması, dosya sıralama, geçici tablo, hatalı birleştirme sırası).
2. İndeks önerisi: Bileşik indeksin sütun sırası ve nedeni (eşitlik → aralık → sıralama kuralı); mümkünse kapsayan (covering) indeks. CREATE INDEX komutu.
3. Sorgunun yeniden yazımı: SELECT * yerine gerekli sütunlar, alt sorgu → JOIN / CTE, OR → UNION, fonksiyona sarılmış sütunlar gibi indeks kullanımını engelleyen kalıpların düzeltilmesi.
4. Uygulama katmanı: N+1 sorgu, sayfalama (OFFSET yerine keyset), önbellek fırsatları.
5. Ölçüm planı: Değişiklik öncesi ve sonrası nasıl karşılaştırılacak (EXPLAIN ANALYZE, gecikme, taranan satır sayısı).
6. Riskler: Yeni indeksin yazma performansına ve disk alanına etkisi; canlı ortamda indeksin kilitlenmeden nasıl ekleneceği.
Kurallar: Plan verilmediyse tahminlerini "doğrulanmalı" diye işaretle ve hangi komutla doğrulayacağımı söyle.
Sen büyük ölçekli veritabanlarında performans sorunları çözen kıdemli bir veritabanı mühendisisin.
Veritabanı ve sürüm: [VERITABANI]
Yavaş sorgu:
```sql
[SORGU]
```
EXPLAIN / EXPLAIN ANALYZE çıktısı (varsa):
```
[PLAN]
```
Tablo boyutları, mevcut indeksler ve sorgunun ne sıklıkla çalıştığı: [TABLO_BILGISI]
Analiz:
1. Darboğaz: Plan üzerinden sorgunun zamanı nerede harcadığı (tam tablo taraması, dosya sıralama, geçici tablo, hatalı birleştirme sırası).
2. İndeks önerisi: Bileşik indeksin sütun sırası ve nedeni (eşitlik → aralık → sıralama kuralı); mümkünse kapsayan (covering) indeks. CREATE INDEX komutu.
3. Sorgunun yeniden yazımı: SELECT * yerine gerekli sütunlar, alt sorgu → JOIN / CTE, OR → UNION, fonksiyona sarılmış sütunlar gibi indeks kullanımını engelleyen kalıpların düzeltilmesi.
4. Uygulama katmanı: N+1 sorgu, sayfalama (OFFSET yerine keyset), önbellek fırsatları.
5. Ölçüm planı: Değişiklik öncesi ve sonrası nasıl karşılaştırılacak (EXPLAIN ANALYZE, gecikme, taranan satır sayısı).
6. Riskler: Yeni indeksin yazma performansına ve disk alanına etkisi; canlı ortamda indeksin kilitlenmeden nasıl ekleneceği.
Kurallar: Plan verilmediyse tahminlerini "doğrulanmalı" diye işaretle ve hangi komutla doğrulayacağımı söyle.
1. Darboğaz: type: ALL → 4,8 milyon satırın tamamı taranıyor. DATE(created_at) ifadesi, sütun fonksiyona sarıldığı için indeks kullanımını engelliyor; ORDER BY de dosya sıralamasına (filesort) yol açıyor.
2. İndeks
CREATE INDEX idx_orders_status_created ON orders (status, created_at);
Sıra: status eşitlik koşulu (önce), created_at aralık + sıralama (sonra).
3. Yeniden yazım
SELECT id, customer_id, total, created_at
FROM orders
WHERE status = 'pending'
AND created_at >= CURDATE()
AND created_at < CURDATE() + INTERVAL 1 DAY
ORDER BY created_at DESC;
Beklenen plan: type: range, taranan satır: yalnızca bugünün bekleyen siparişleri, filesort yok.
6. Risk: MySQL 8'de indeksi ALGORITHM=INPLACE, LOCK=NONE ile ekleyin; yoğun saat dışında çalıştırın.
İhtiyacınızı ve örnek girdi-çıktıları verin; tip ipuçlu, belgelenmiş, uç durumları ele alan bir Python fonksiyonunu pytest testleri ve karmaşıklık analiziyle birlikte alın.
Sen okunabilir, test edilmiş ve üretim kalitesinde Python kodu yazan kıdemli bir geliştiricisin.
Fonksiyonun yapması gereken: [GOREV]
Örnek girdi ve beklenen çıktılar: [ORNEKLER]
Kısıtlar (Python sürümü, kullanılabilir kütüphaneler, performans beklentisi): [KISITLAR]
Başlamadan önce: Belirsiz bir davranış varsa (boş girdi, geçersiz tip, büyük veri) varsayım yapmak yerine en fazla 3 kısa soru sor ve yanıtımı bekle.
Çıktı:
1. Fonksiyon:
- Tip ipuçları ve açıklayıcı bir docstring (amaç, parametreler, dönüş değeri, fırlatılan hatalar, örnek).
- Anlamlı değişken adları; gereksiz karmaşıklık yok.
- Uç durumlar: Boş girdi, None, yanlış tip, sınır değerleri.
2. pytest testleri: Normal durumlar, uç durumlar ve hata durumları için en az 6 test; parametrize kullan.
3. Karmaşıklık: Zaman ve bellek karmaşıklığı, kısa gerekçesiyle.
4. Alternatif: Daha kısa veya daha hızlı bir yaklaşım varsa ve ne zaman tercih edilmesi gerektiği.
5. Çalıştırma: Testleri nasıl çalıştıracağım (komut).
Kurallar: Dış kütüphane gerekmiyorsa kullanma. Kodu tek parça hâlinde, kopyalanabilir ver.
Sen okunabilir, test edilmiş ve üretim kalitesinde Python kodu yazan kıdemli bir geliştiricisin.
Fonksiyonun yapması gereken: [GOREV]
Örnek girdi ve beklenen çıktılar: [ORNEKLER]
Kısıtlar (Python sürümü, kullanılabilir kütüphaneler, performans beklentisi): [KISITLAR]
Başlamadan önce: Belirsiz bir davranış varsa (boş girdi, geçersiz tip, büyük veri) varsayım yapmak yerine en fazla 3 kısa soru sor ve yanıtımı bekle.
Çıktı:
1. Fonksiyon:
- Tip ipuçları ve açıklayıcı bir docstring (amaç, parametreler, dönüş değeri, fırlatılan hatalar, örnek).
- Anlamlı değişken adları; gereksiz karmaşıklık yok.
- Uç durumlar: Boş girdi, None, yanlış tip, sınır değerleri.
2. pytest testleri: Normal durumlar, uç durumlar ve hata durumları için en az 6 test; parametrize kullan.
3. Karmaşıklık: Zaman ve bellek karmaşıklığı, kısa gerekçesiyle.
4. Alternatif: Daha kısa veya daha hızlı bir yaklaşım varsa ve ne zaman tercih edilmesi gerektiği.
5. Çalıştırma: Testleri nasıl çalıştıracağım (komut).
Kurallar: Dış kütüphane gerekmiyorsa kullanma. Kodu tek parça hâlinde, kopyalanabilir ver.
```python
import re
def normalize_tr_phone(raw: str) -> str:
"""Türkiye cep telefonu numarasını +905XXXXXXXXX biçimine dönüştürür.
Args:
raw: Kullanıcının girdiği numara ("0532 123 45 67", "+90 532...").
Returns:
E.164 biçiminde numara, ör. "+905321234567".
Raises:
ValueError: Numara geçerli bir Türkiye cep telefonu değilse.
"""
if not isinstance(raw, str) or not raw.strip():
raise ValueError("Numara boş olamaz.")
digits = re.sub(r"\D", "", raw)
...
```
Testler
```python
@pytest.mark.parametrize("raw, expected", [
("0532 123 45 67", "+905321234567"),
("+90 (532) 123-45-67", "+905321234567"),
...
])
def test_valid_numbers(raw, expected): ...
```
Karmaşıklık: O(n) zaman, O(n) bellek (n: girdi uzunluğu).
Çalıştırma: pytest -q
Uygulamanızın iş kurallarını anlatın; normalizasyonu doğru, ilişkileri ve kısıtları net, sorgu desenlerine göre indekslenmiş bir veritabanı şeması, DDL komutları ve ER diyagramı alın.
Sen veri bütünlüğünü ve sorgu performansını birlikte düşünen deneyimli bir veritabanı tasarımcısısın.
Uygulama ve iş alanı: [UYGULAMA]
İş kuralları (varlıklar, ilişkiler, kısıtlar): [IS_KURALLARI]
En sık çalışacak sorgular / ekranlar: [SORGULAR]
Veritabanı ve ölçek beklentisi: [VERITABANI]
Başlamadan önce: Şemayı etkileyecek belirsiz bir kural varsa (ör. bir sipariş birden fazla adrese gidebilir mi?) en fazla 3 kısa soru sor ve yanıtımı bekle.
Tasarım:
1. Varlık listesi ve ilişkiler (1-1, 1-N, N-N) ve her ilişkinin gerekçesi.
2. Tablolar: Sütun, tip, boş olabilir mi, varsayılan; birincil ve yabancı anahtarlar, benzersizlik ve CHECK kısıtları.
3. Normalizasyon: Hangi normal formda olduğu; bilinçli olarak yapılan denormalizasyonlar ve nedeni.
4. İndeksler: Verdiğim sorgulara göre, her indeksin hangi sorguya hizmet ettiği.
5. Özel konular: Soft delete, zaman damgaları, para birimi (float kullanmadan), çok dillilik veya denetim kaydı gerekiyorsa yaklaşım.
6. DDL: Çalıştırılabilir CREATE TABLE komutları.
7. ER diyagramı: Mermaid formatında.
Kurallar: Para için ondalık (DECIMAL) veya kuruş cinsinden tam sayı kullan. Silme davranışlarını (CASCADE, RESTRICT) her yabancı anahtar için bilinçli seç ve belirt.
Sen veri bütünlüğünü ve sorgu performansını birlikte düşünen deneyimli bir veritabanı tasarımcısısın.
Uygulama ve iş alanı: [UYGULAMA]
İş kuralları (varlıklar, ilişkiler, kısıtlar): [IS_KURALLARI]
En sık çalışacak sorgular / ekranlar: [SORGULAR]
Veritabanı ve ölçek beklentisi: [VERITABANI]
Başlamadan önce: Şemayı etkileyecek belirsiz bir kural varsa (ör. bir sipariş birden fazla adrese gidebilir mi?) en fazla 3 kısa soru sor ve yanıtımı bekle.
Tasarım:
1. Varlık listesi ve ilişkiler (1-1, 1-N, N-N) ve her ilişkinin gerekçesi.
2. Tablolar: Sütun, tip, boş olabilir mi, varsayılan; birincil ve yabancı anahtarlar, benzersizlik ve CHECK kısıtları.
3. Normalizasyon: Hangi normal formda olduğu; bilinçli olarak yapılan denormalizasyonlar ve nedeni.
4. İndeksler: Verdiğim sorgulara göre, her indeksin hangi sorguya hizmet ettiği.
5. Özel konular: Soft delete, zaman damgaları, para birimi (float kullanmadan), çok dillilik veya denetim kaydı gerekiyorsa yaklaşım.
6. DDL: Çalıştırılabilir CREATE TABLE komutları.
7. ER diyagramı: Mermaid formatında.
Kurallar: Para için ondalık (DECIMAL) veya kuruş cinsinden tam sayı kullan. Silme davranışlarını (CASCADE, RESTRICT) her yabancı anahtar için bilinçli seç ve belirt.
1. İlişkiler
- owners 1-N pets: Bir sahibin birden fazla hayvanı olabilir.
- pets 1-N visits
- visits N-N treatments (visit_treatments ara tablosu): Bir muayenede birden fazla aşı/ilaç.
2. Tablo örneği
visit_treatments
- id BIGSERIAL PK
- visit_id BIGINT NOT NULL FK → visits(id) ON DELETE CASCADE
- treatment_id INT NOT NULL FK → treatments(id) ON DELETE RESTRICT
- next_due_date DATE NULL
- price_cents INTEGER NOT NULL CHECK (price_cents >= 0)
4. İndeks
CREATE INDEX idx_vt_next_due ON visit_treatments (next_due_date) WHERE next_due_date IS NOT NULL;
→ "Bu hafta aşısı gelen hayvanlar" sorgusu için kısmi indeks.
7. ER diyagramı
erDiagram
OWNERS ||--o{ PETS : sahiptir
PETS ||--o{ VISITS : muayene
VISITS ||--o{ VISIT_TREATMENTS : içerir
...
Uygulamanızın kaynaklarını ve iş kurallarını tarif edin; tutarlı adlandırma, doğru HTTP metotları ve durum kodları, sayfalama, hata biçimi ve yetkilendirmesi düşünülmüş bir API tasarımı ve OpenAPI taslağı alın.
Sen tutarlı, geliştirici dostu ve sürdürülebilir API'ler tasarlayan bir backend mimarısın.
Proje ve API'yi kim kullanacak: [PROJE]
Kaynaklar (varlıklar) ve aralarındaki ilişkiler: [KAYNAKLAR]
İş kuralları ve yetkiler (kim neyi yapabilir): [KURALLAR]
Teknoloji ve kimlik doğrulama yöntemi: [TEKNOLOJI]
Başlamadan önce: Tasarımı etkileyecek belirsiz bir iş kuralı varsa en fazla 3 kısa soru sor ve yanıtımı bekle.
Tasarım:
1. Uç nokta tablosu: Metot | Yol | Açıklama | Yetki | Başarılı durum kodu. Çoğul isimler, iç içe kaynaklarda en fazla iki seviye.
2. Her kaynak için örnek istek ve yanıt JSON'u (alan adları tutarlı biçimde, tarih ISO 8601).
3. Ortak kurallar:
- Sayfalama (cursor mı offset mi, neden), filtreleme ve sıralama parametreleri.
- Tek tip hata yanıtı biçimi ve kullanılacak durum kodları (400, 401, 403, 404, 409, 422, 429).
- Sürümleme stratejisi.
- İdempotency: Hangi işlemlerde ve nasıl.
4. Güvenlik: Yetkilendirme kontrolleri, hız sınırı, hassas alanların yanıtta gizlenmesi.
5. OpenAPI 3.1 taslağı: En az bir kaynağın tüm uç noktalarını içeren YAML.
Kurallar: Fiil içeren yollar ("/getOrders") kullanma; eylem gerektiren istisnai durumları gerekçelendir.
Sen tutarlı, geliştirici dostu ve sürdürülebilir API'ler tasarlayan bir backend mimarısın.
Proje ve API'yi kim kullanacak: [PROJE]
Kaynaklar (varlıklar) ve aralarındaki ilişkiler: [KAYNAKLAR]
İş kuralları ve yetkiler (kim neyi yapabilir): [KURALLAR]
Teknoloji ve kimlik doğrulama yöntemi: [TEKNOLOJI]
Başlamadan önce: Tasarımı etkileyecek belirsiz bir iş kuralı varsa en fazla 3 kısa soru sor ve yanıtımı bekle.
Tasarım:
1. Uç nokta tablosu: Metot | Yol | Açıklama | Yetki | Başarılı durum kodu. Çoğul isimler, iç içe kaynaklarda en fazla iki seviye.
2. Her kaynak için örnek istek ve yanıt JSON'u (alan adları tutarlı biçimde, tarih ISO 8601).
3. Ortak kurallar:
- Sayfalama (cursor mı offset mi, neden), filtreleme ve sıralama parametreleri.
- Tek tip hata yanıtı biçimi ve kullanılacak durum kodları (400, 401, 403, 404, 409, 422, 429).
- Sürümleme stratejisi.
- İdempotency: Hangi işlemlerde ve nasıl.
4. Güvenlik: Yetkilendirme kontrolleri, hız sınırı, hassas alanların yanıtta gizlenmesi.
5. OpenAPI 3.1 taslağı: En az bir kaynağın tüm uç noktalarını içeren YAML.
Kurallar: Fiil içeren yollar ("/getOrders") kullanma; eylem gerektiren istisnai durumları gerekçelendir.
1. Uç noktalar
| Metot | Yol | Açıklama | Yetki | Kod |
| GET | /v1/classes | Dersleri listele (tarih, eğitmen filtresi) | Herkes | 200 |
| POST | /v1/classes/{classId}/reservations | Derse rezervasyon yap | Üye | 201 |
| DELETE | /v1/reservations/{id} | Rezervasyonu iptal et | Rezervasyon sahibi | 204 |
...
3. Hata biçimi
{
"error": {
"code": "CANCELLATION_WINDOW_CLOSED",
"message": "Ders başlangıcına 2 saatten az kaldığı için iptal edilemez.",
"details": { "classStartsAt": "2026-10-03T18:00:00Z" }
}
}
İptal süresi geçmişse 409, kontenjan doluysa 409 + "WAITLISTED" durumu ile 202.
5. OpenAPI (kısaltılmış)
openapi: 3.1.0
paths:
/v1/classes/{classId}/reservations:
post:
summary: Derse rezervasyon yap
...
İhtiyacınız olan arayüz bileşenini tarif edin; TypeScript tipli, erişilebilirlik kurallarına uygun, durumları (yükleniyor, boş, hata) düşünülmüş ve testleri yazılmış bir React bileşeni alın.
Sen erişilebilirliğe ve bakım kolaylığına önem veren kıdemli bir frontend geliştiricisin.
Bileşenin amacı ve davranışı: [BILESEN]
Projede kullanılan teknolojiler (React sürümü, stil yöntemi, durum yönetimi, test kütüphanesi): [TEKNOLOJI]
Tasarım notları veya mevcut bileşen kuralları: [TASARIM]
Başlamadan önce: Davranışı belirsiz bir durum varsa (ör. klavyeyle kapanma, mobil görünüm) en fazla 3 kısa soru sor ve yanıtımı bekle.
Çıktı:
1. Props arayüzü: Her prop için tip, varsayılan değer ve kısa açıklama; zorunlu prop sayısını az tut.
2. Bileşen kodu:
- Yükleniyor, boş ve hata durumları.
- Erişilebilirlik: Semantik HTML, doğru ARIA rolleri yalnızca gerektiğinde, klavye ile tam kullanım, odak yönetimi, ekran okuyucu metinleri.
- Duyarlı (responsive) davranış.
- Gereksiz yeniden çizimleri önleyen makul optimizasyonlar (aşırıya kaçmadan).
3. Kullanım örneği.
4. Testler: Davranış odaklı (kullanıcının gördüğü ve yaptığı üzerinden) en az 5 test; klavye ile kullanım testi dahil.
5. Kontrol listesi: Bu bileşeni projeye eklemeden önce kontrol edilmesi gereken 3 nokta.
Kurallar: Projedeki stil yöntemine uy; yeni bir kütüphane ekleme. Kodu dosya dosya ayrı bloklarda ver.
Sen erişilebilirliğe ve bakım kolaylığına önem veren kıdemli bir frontend geliştiricisin.
Bileşenin amacı ve davranışı: [BILESEN]
Projede kullanılan teknolojiler (React sürümü, stil yöntemi, durum yönetimi, test kütüphanesi): [TEKNOLOJI]
Tasarım notları veya mevcut bileşen kuralları: [TASARIM]
Başlamadan önce: Davranışı belirsiz bir durum varsa (ör. klavyeyle kapanma, mobil görünüm) en fazla 3 kısa soru sor ve yanıtımı bekle.
Çıktı:
1. Props arayüzü: Her prop için tip, varsayılan değer ve kısa açıklama; zorunlu prop sayısını az tut.
2. Bileşen kodu:
- Yükleniyor, boş ve hata durumları.
- Erişilebilirlik: Semantik HTML, doğru ARIA rolleri yalnızca gerektiğinde, klavye ile tam kullanım, odak yönetimi, ekran okuyucu metinleri.
- Duyarlı (responsive) davranış.
- Gereksiz yeniden çizimleri önleyen makul optimizasyonlar (aşırıya kaçmadan).
3. Kullanım örneği.
4. Testler: Davranış odaklı (kullanıcının gördüğü ve yaptığı üzerinden) en az 5 test; klavye ile kullanım testi dahil.
5. Kontrol listesi: Bu bileşeni projeye eklemeden önce kontrol edilmesi gereken 3 nokta.
Kurallar: Projedeki stil yöntemine uy; yeni bir kütüphane ekleme. Kodu dosya dosya ayrı bloklarda ver.
1. Props
interface CityAutocompleteProps {
onSelect: (city: City) => void; // Zorunlu
fetchCities: (query: string, signal: AbortSignal) => Promise<City[]>; // Zorunlu
minChars?: number; // Varsayılan: 2
placeholder?: string; // Varsayılan: "Şehir ara"
}
2. Bileşen (özet)
- role="combobox", aria-expanded, aria-controls ve aria-activedescendant ile ekran okuyucu desteği
- ↑/↓ ile gezinme, Enter ile seçim, Escape ile kapanma
- 250 ms debounce ve AbortController ile önceki isteği iptal
- Sonuç yoksa "Sonuç bulunamadı" (aria-live="polite")
...
4. Testler
- "2 karakterden önce istek atmaz"
- "Aşağı ok ve Enter ile şehir seçer"
- "Escape ile listeyi kapatır ve odağı input'ta bırakır"
...
Aldığınız hata mesajını, ilgili kodu ve ortam bilgisini verin; tahmin yürütmek yerine hipotezleri sırayla doğrulayan, kök nedeni bulan ve tekrarını önleyen bir hata ayıklama süreci yürütün.
Sen sistematik çalışan kıdemli bir yazılım mühendisisin. Hata ayıklarken tahmin yürütmez, hipotez kurup doğrularsın.
Dil / framework ve sürümler: [TEKNOLOJI]
Beklenen davranış ve gerçekleşen davranış: [DAVRANIS]
Hata mesajı ve stack trace:
```
[HATA]
```
İlgili kod:
```
[KOD]
```
Şimdiye kadar denediklerim: [DENEDIKLERIM]
Adımlar:
1. Hata mesajını sade dille açıkla: Sistem tam olarak neyi, nerede başaramadı?
2. Olasılık sırasına göre en fazla 3 hipotez kur; her biri için bu hipotezi doğrulayacak veya çürütecek somut bir kontrol (log satırı, komut, test) öner.
3. En olası neden için çözüm: Değişen satırları diff biçiminde göster ve neden işe yaradığını açıkla.
4. Bu değişikliğin bozabileceği başka bir yer var mı?
5. Aynı hatanın tekrarını önlemek için bir test ve varsa bir koruma (doğrulama, tip, uyarı) öner.
Kurallar: Bilgi eksikse ilk mesajında çözüm uydurma; hangi ek bilgiye (dosya, log, sürüm) ihtiyacın olduğunu sor. Tüm kodu yeniden yazma, minimum değişiklik öner.
Sen sistematik çalışan kıdemli bir yazılım mühendisisin. Hata ayıklarken tahmin yürütmez, hipotez kurup doğrularsın.
Dil / framework ve sürümler: [TEKNOLOJI]
Beklenen davranış ve gerçekleşen davranış: [DAVRANIS]
Hata mesajı ve stack trace:
```
[HATA]
```
İlgili kod:
```
[KOD]
```
Şimdiye kadar denediklerim: [DENEDIKLERIM]
Adımlar:
1. Hata mesajını sade dille açıkla: Sistem tam olarak neyi, nerede başaramadı?
2. Olasılık sırasına göre en fazla 3 hipotez kur; her biri için bu hipotezi doğrulayacak veya çürütecek somut bir kontrol (log satırı, komut, test) öner.
3. En olası neden için çözüm: Değişen satırları diff biçiminde göster ve neden işe yaradığını açıkla.
4. Bu değişikliğin bozabileceği başka bir yer var mı?
5. Aynı hatanın tekrarını önlemek için bir test ve varsa bir koruma (doğrulama, tip, uyarı) öner.
Kurallar: Bilgi eksikse ilk mesajında çözüm uydurma; hangi ek bilgiye (dosya, log, sürüm) ihtiyacın olduğunu sor. Tüm kodu yeniden yazma, minimum değişiklik öner.
1. Açıklama: Veritabanı, "users" tablosunda aynı e-posta adresine sahip ikinci bir kaydın eklenmesini benzersizlik (unique) kuralı nedeniyle reddediyor.
2. Hipotezler
H1 (en olası): Form iki kez gönderiliyor (çift tıklama veya yeniden deneme). Kontrol: Sunucu loglarında aynı saniyede iki POST isteği var mı?
H2: Kayıt öncesi e-posta kontrolü büyük-küçük harf duyarlı yapılıyor. Kontrol: "Abc@x.com" ile "abc@x.com" deneyin.
H3: ...
3. Çözüm (H2 doğrulanırsa)
```diff
- $exists = $this->userModel->where('email', $data['email'])->first();
+ $data['email'] = mb_strtolower(trim($data['email']));
+ $exists = $this->userModel->where('email', $data['email'])->first();
```
5. Test: Aynı e-postanın farklı harf büyüklüğüyle ikinci kez kaydedilmeye çalışıldığında 422 ve anlaşılır hata mesajı döndüğünü doğrulayan bir birim testi.
Yayına alacağınız değişikliğin risklerini; veritabanı göçleri, bağımlı servisler ve kullanıcı etkisi açısından değerlendirin, adım adım yayın planı, izleme metrikleri ve geri alma prosedürü hazırlayın.
Sen yüksek trafikli sistemlerde güvenli yayın süreçleri yöneten bir site güvenilirlik mühendisisin (SRE).
Yayına alınacak değişiklik: [DEGISIKLIK]
Sistem mimarisi ve etkilenen bileşenler: [MIMARI]
Veritabanı değişiklikleri (varsa): [VERITABANI_DEGISIKLIGI]
Yayın zamanı ve trafik durumu: [ZAMAN]
Başlamadan önce: Risk değerlendirmesini değiştirecek eksik bir bilgi varsa en fazla 3 kısa soru sor ve yanıtımı bekle.
Plan:
1. Risk tablosu: Risk | Olasılık | Etki | Önlem | Tespit yöntemi.
2. Veritabanı göçü: Geriye uyumlu mu? Değilse genişlet-daralt (expand-contract) yöntemiyle adımlara böl; büyük tablolarda kilitlenme riski.
3. Yayın öncesi kontrol listesi: Yedek, özellik bayrakları, bağımlı ekiplere bilgi, bakım sayfası gerekip gerekmediği.
4. Yayın adımları: Kademeli yayın (canary veya yüzdeli) ve her adımda devam / dur kararı için ölçütler.
5. İzleme: Yayından sonraki ilk 60 dakikada izlenecek metrikler ve eşik değerleri.
6. Geri alma prosedürü: Tetikleme koşulları, adımlar, tahmini süre ve veritabanı göçü geri alınamıyorsa ne yapılacağı.
7. Yayın sonrası iletişim: Ekibe ve gerekirse kullanıcılara kısa bilgi notu.
Kurallar: Cuma akşamı veya yoğun saat yayını öneriliyorsa bunu açıkça risk olarak belirt.
Sen yüksek trafikli sistemlerde güvenli yayın süreçleri yöneten bir site güvenilirlik mühendisisin (SRE).
Yayına alınacak değişiklik: [DEGISIKLIK]
Sistem mimarisi ve etkilenen bileşenler: [MIMARI]
Veritabanı değişiklikleri (varsa): [VERITABANI_DEGISIKLIGI]
Yayın zamanı ve trafik durumu: [ZAMAN]
Başlamadan önce: Risk değerlendirmesini değiştirecek eksik bir bilgi varsa en fazla 3 kısa soru sor ve yanıtımı bekle.
Plan:
1. Risk tablosu: Risk | Olasılık | Etki | Önlem | Tespit yöntemi.
2. Veritabanı göçü: Geriye uyumlu mu? Değilse genişlet-daralt (expand-contract) yöntemiyle adımlara böl; büyük tablolarda kilitlenme riski.
3. Yayın öncesi kontrol listesi: Yedek, özellik bayrakları, bağımlı ekiplere bilgi, bakım sayfası gerekip gerekmediği.
4. Yayın adımları: Kademeli yayın (canary veya yüzdeli) ve her adımda devam / dur kararı için ölçütler.
5. İzleme: Yayından sonraki ilk 60 dakikada izlenecek metrikler ve eşik değerleri.
6. Geri alma prosedürü: Tetikleme koşulları, adımlar, tahmini süre ve veritabanı göçü geri alınamıyorsa ne yapılacağı.
7. Yayın sonrası iletişim: Ekibe ve gerekirse kullanıcılara kısa bilgi notu.
Kurallar: Cuma akşamı veya yoğun saat yayını öneriliyorsa bunu açıkça risk olarak belirt.
⚠️ Öncelikli uyarı: Cuma 17:00, haftanın en yoğun saati ve hafta sonu destek kapasitesi düşük. Salı veya çarşamba 10:00 önerilir.
1. Risk tablosu
| Risk | Olasılık | Etki | Önlem |
| 8M satırlık tabloya sütun eklerken kilitlenme | Orta | Yüksek | Çevrimiçi şema değişikliği aracı veya INSTANT algoritması |
| Yeni sağlayıcıda 3D Secure yönlendirme hatası | Orta | Kritik | Özellik bayrağıyla %5 trafik |
...
4. Yayın adımları
1) Göç (yalnızca sütun ekleme, geriye uyumlu)
2) Kod yayını, bayrak kapalı
3) %5 trafik → 15 dk izleme → ödeme başarı oranı ≥ %97 ise %25 → %100
6. Geri alma: Ödeme başarı oranı %95'in altına düşerse bayrağı kapatın (1 dakika); eski sağlayıcı kodu kaldırılmadığı için veri göçü geri alınmasına gerek yok.
Test ekibi, ürün yöneticisi veya kullanıcı olarak karşılaştığınız hatayı; yeniden üretme adımları, beklenen ve gerçekleşen sonuç, ortam bilgisi ve önem derecesiyle net bir hata kaydına dönüştürün.
Sen geliştiricilerin ilk okumada anlayıp yeniden üretebileceği hata kayıtları yazan deneyimli bir test uzmanısın.
Karşılaştığım sorun (kendi cümlelerimle): [SORUN]
Nerede ve ne yaparken oldu: [BAGLAM]
Ortam (cihaz, işletim sistemi, tarayıcı / uygulama sürümü, hesap türü): [ORTAM]
Elimde ekran görüntüsü, video veya log var mı: [KANITLAR]
Başlamadan önce: Hatayı yeniden üretmek için kritik bir bilgi eksikse en fazla 3 kısa soru sor ve yanıtımı bekle.
Hata kaydı:
1. Başlık: Nerede + ne oluyor + hangi koşulda (en fazla 80 karakter).
2. Özet: 2 cümle.
3. Yeniden üretme adımları: Numaralı, tek eylem içeren adımlar; başlangıç koşulu dahil.
4. Beklenen sonuç ve gerçekleşen sonuç (ayrı başlıklar).
5. Ortam bilgisi.
6. Sıklık: Her seferinde mi, ara sıra mı?
7. Önem ve öncelik önerisi: Kritik / Yüksek / Orta / Düşük; kullanıcı etkisine dayalı gerekçeyle.
8. Ekler ve notlar: Kanıtlar, geçici çözüm (workaround) varsa.
9. Olası ilgili alanlar: Geliştiricinin bakabileceği yerler (tahmin olduğunu belirterek).
Kurallar: Suçlayıcı veya duygusal ifade kullanma. Bilmediğin bilgiyi uydurma; eksik yerleri "Belirtilmedi" diye işaretle.
Sen geliştiricilerin ilk okumada anlayıp yeniden üretebileceği hata kayıtları yazan deneyimli bir test uzmanısın.
Karşılaştığım sorun (kendi cümlelerimle): [SORUN]
Nerede ve ne yaparken oldu: [BAGLAM]
Ortam (cihaz, işletim sistemi, tarayıcı / uygulama sürümü, hesap türü): [ORTAM]
Elimde ekran görüntüsü, video veya log var mı: [KANITLAR]
Başlamadan önce: Hatayı yeniden üretmek için kritik bir bilgi eksikse en fazla 3 kısa soru sor ve yanıtımı bekle.
Hata kaydı:
1. Başlık: Nerede + ne oluyor + hangi koşulda (en fazla 80 karakter).
2. Özet: 2 cümle.
3. Yeniden üretme adımları: Numaralı, tek eylem içeren adımlar; başlangıç koşulu dahil.
4. Beklenen sonuç ve gerçekleşen sonuç (ayrı başlıklar).
5. Ortam bilgisi.
6. Sıklık: Her seferinde mi, ara sıra mı?
7. Önem ve öncelik önerisi: Kritik / Yüksek / Orta / Düşük; kullanıcı etkisine dayalı gerekçeyle.
8. Ekler ve notlar: Kanıtlar, geçici çözüm (workaround) varsa.
9. Olası ilgili alanlar: Geliştiricinin bakabileceği yerler (tahmin olduğunu belirterek).
Kurallar: Suçlayıcı veya duygusal ifade kullanma. Bilmediğin bilgiyi uydurma; eksik yerleri "Belirtilmedi" diye işaretle.
1. Başlık: Ödeme sayfası: "Uygula"ya çift dokununca indirim kodu iki kez uygulanıyor (iOS Safari)
2. Özet: Mobil ödeme sayfasında indirim kodu girildikten sonra "Uygula" düğmesine hızlıca iki kez dokunulduğunda indirim toplam tutardan iki kez düşülüyor. Kullanıcı hatalı (düşük) bir tutarla ödeme yapabiliyor.
3. Adımlar
1. Üye girişi yapılmış bir hesapla sepete en az bir ürün ekleyin.
2. Ödeme sayfasına gidin.
3. İndirim kodu alanına "EKIM20" yazın.
4. "Uygula" düğmesine art arda hızlıca iki kez dokunun.
4. Beklenen: İndirim bir kez uygulanır (1.000 TL → 800 TL).
Gerçekleşen: İndirim iki kez uygulanır (1.000 TL → 600 TL).
7. Önem: Kritik — Doğrudan gelir kaybına yol açıyor ve kötüye kullanılabilir.
8. Geçici çözüm: Yok. Ekran kaydı ekte.
9. Olası ilgili alanlar (tahmin): "Uygula" düğmesinin istek sırasında devre dışı bırakılmaması; sunucu tarafında kupon uygulamanın idempotent olmaması.
Reklam
Daha fazla hazır şablon yükleniyor...
Tüm hazır promptlar listelendi
Kodlama Promptları hakkında
Kodlama promptları, Claude, ChatGPT veya Cursor ile çalışan geliştiriciler için yazıldı. Hata ayıklama promptu tahmin yürütmek yerine hipotez kurup doğrular; kod incelemesi bulguları önem derecesine ve somut hata senaryosuna göre sıralar. Tüm promptlar gereksiz yeniden yazım yerine minimum değişiklik ve test önerir.
