Kod prompt kütüphanesi - Ürfet Demirtaş

ROL: Kıdemli bir .NET mimarısın.
BAĞLAM: .NET 9, stateless bir ödeme API’si. Yeni POS/banka sağlayıcısı eklemek ‘bir sınıf yaz + DI’ye ekle’ kadar kolay olmalı.
MİMARİ: Clean Architecture katmanları (Domain / Application / Infrastructure / Api) + Strategy Pattern (IPaymentGateway).
İSTE:
1) IPaymentGateway arayüzü (ChargeAsync, RefundAsync; CancellationToken)
2) Sağlayıcı seçimi için resolver (isim/enum → gateway), if/switch yığını YOK
3) ChargeRequest/ChargeResult DTO’ları (idempotencyKey dahil)
4) Idempotency stratejisi (aynı anahtar → aynı sonuç, çift tahsil yok)
5) Uzantı noktaları: JWT auth middleware, IP allowlist filter, IAuditStore
6) Minimal API endpoint örneği + DI kaydı
KISIT: Gerçek banka sırrı/endpoint/kart numarası YOK; sağlayıcı adı ‘DemoBank’. Exploit/güvenlik bypass yazma. Her kritik kararın yanına 1 satır yorum.
ÇIKTI: Derlenebilir iskelet kod + kısa README maddeleri (kurulum, yeni sağlayıcı ekleme adımı).

ÇIKTI (kısaltılmış iskelet)

public interface IPaymentGateway {
    string Name { get; }
    Task<ChargeResult> ChargeAsync(ChargeRequest req, CancellationToken ct);
}

public sealed record ChargeRequest(string IdempotencyKey, decimal Amount, string Currency);
public sealed record ChargeResult(string Status, string ProviderRef);

// Yeni sağlayıcı = yeni sınıf. Resolver dictionary’den seçer, switch yok.
public sealed class GatewayResolver {
    private readonly Dictionary<string, IPaymentGateway> _map;
    public GatewayResolver(IEnumerable<IPaymentGateway> gws) => _map = gws.ToDictionary(g => g.Name);
    public IPaymentGateway Get(string name) => _map[name];
}

// Idempotency: aynı anahtar ikinci kez → kayıtlı sonuç döner (no-op).

Uzantı: JWT middleware · IP allowlist filter · IAuditStore.
YENİ SAĞLAYICI: sınıf yaz → IPaymentGateway uygula → DI’ye ekle. Kayıt değişmez.
YOK: kart no, banka sırrı, exploit.

KONTROL: + Strategy + resolver, switch yığını yok + Idempotency var + Gerçek sır/kart yok

ROL: Kurumsal AI platform mühendisisin.
BAĞLAM: İnternetsiz / veri dışarı çıkmayan bir ortamda lokal LLM (Qwen sınıfı) + RAG kurulacak. Dil: C# + Python karışık kabul.
GÖREV: Canlıya alınabilir bir entegrasyon planı üret (demo değil).
İSTE:
1) Bileşen mimarisi: inference (Qwen), embedding servisi, vektör DB, .NET API (yetki+sorgu), ingest worker (belge→chunk) — her biri neden orada
2) API sözleşmesi: POST /ask ve POST /ingest istek/yanıt şeması (JSON), hata kodları
3) Chunk stratejisi: boyut, örtüşme, başlık koruma, tablo/başlık ayrımı; neden bu değerler
4) Güvenlik sınırları: tenant izolasyonu, çıkış (egress) engeli, PII log yasağı, kaynak-yoksa-cevap-yok kuralı
5) İlk sprint iş kırılımı: 1-2 haftalık gerçekçi görevler (INVEST), ‘bitti’ tanımı
6) Riskler + ölçüm: hangi metrikle doğrularsın (retrieval isabet, cevap kaynaklılığı)
KISIT: Model ağırlığı/telif isteme; güvenlik bypass yazma. Varsayımları açıkça işaretle.

ÇIKTI (özet plan)

Bileşen
- Qwen (lokal inference, GPU node)
- Embedding servisi (aynı ağ, dışarı çıkış yok)
- Vektör DB (tenant kolonlu)
- .NET API (auth + sorgu orkestrasyonu)
- Ingest worker (PDF/DOCX → chunk → embedding)

API
POST /ingest { tenantId, docId, bytes } → { chunks, status }
POST /ask { tenantId, query, topK } → { answer, sources[], usedChunks }
Hata: 401 tenant, 422 boş sorgu, 424 kaynak yok.

Chunk
800-1200 karakter, 150 örtüşme, başlık chunk’a taşınır, tablo ayrı. (Varsayım: teknik doküman ağırlıklı.)

Güvenlik
Egress firewall · tenant izolasyonu · PII log’da yasak · kaynaksız cevap üretme.

Sprint 1
Ingest hattı + /ask + kaynak listesi. Bitti = 20 belgede kaynaklı cevap. UI cilası yok.

Ölçüm: retrieval isabet@5, cevap-kaynak eşleşme oranı.

KONTROL: + Canlı plan, demo değil + Güvenlik sınırları net + Varsayımlar işaretli

ROL: Observability mühendisisin (Serilog + Grafana Loki).
GÖREV: Verilen Serilog yapılandırmasını ve örnek log satırlarını incele.
HEDEF: (1) PII sızmasın, (2) label cardinality patlamasın, (3) Loki’de sorgulanabilir olsun.
ÇIKTI:
1) Bulgular: önem sırasıyla (Yüksek/Orta/Düşük), her biri dosya/satır tahmini + neden
2) Düzeltilmiş yapılandırma: label allowlist, dinamik değeri (URL/id) label’dan structured field’a taşı, enrich (service/env)
3) Cardinality kuralı: hangi alan asla label olmaz (userId, path, guid)
4) 5 örnek LogQL: hata arama, oran, cardinality izleme, status filtresi, idempotency izi
5) 1 alarm önerisi (seri sayısı tavanı)
KISIT: PII maskeleme örneğinde gerçek veri üretme. Kod:

{KOD}

ÖRNEK DEĞİŞKEN
KOD: RequestPath ve Email label olarak yazılıyor

ÇIKTI
Bulgular
- Yüksek: RequestPath ham URL label → her URL yeni seri (cardinality patlaması)
- Yüksek: Email label → PII sızıntısı
- Orta: MessageTemplate yok → Loki’de gruplanamıyor

Düzeltme (özet)
RequestPath → route template (‘/orders/{id}’). Email → SHA256 hash. UserId structured field, label değil. Enrich: service, env. Label allowlist: {service, env, level}.

Cardinality kuralı: path, userId, guid, email ASLA label olmaz.

LogQL
1) {service="payments"} |= "timeout"
2) sum by (level) (rate({service="payments"}[5m]))
3) count_over_time({service="payments"}[5m])
4) {service="payments"} | json | status="500"
5) {service="payments"} |~ "idempotency"

Alarm: benzersiz seri > tavan → uyar.

KONTROL: + PII maskelendi + Cardinality kuralı net + Gerçek veri üretilmedi

ROL: Veritabanı performans uzmanısın (SQL Server / PostgreSQL).
GÖREV: Verilen yavaş sorguyu iyileştir.
ÇIKTI:
1) Neden yavaş: sargability, fonksiyonla sarılmış kolon, SELECT *, eksik indeks, implicit conversion — hangisi ve neden
2) Yeniden yazılmış sorgu: sargable WHERE, gerekli kolonlar, gerekiyorsa CTE/pencere fonksiyonu
3) Önerilen indeks(ler): tam tanım (INCLUDE dahil) + hangi predicate’i karşılıyor
4) Beklenen plan değişimi: scan → seek gibi, tahmini etki
5) Riskler: yazma maliyeti, indeks bakımı, aralık hatası
KISIT: DROP, TRUNCATE veya production’da veri silme önerme. Gerçek veriyle test uydurma; ‘kendi datanla ölç’ de. Sorgu:

{SQL}

ÖRNEK DEĞİŞKEN
SQL: WHERE YEAR(CreatedAt) = 2026 ile filtreleyen SELECT * (Orders)

ÇIKTI
Neden yavaş
- YEAR(CreatedAt) kolonu sarıyor → indeks kullanılamıyor (non-sargable), tam tarama.
- SELECT * gereksiz kolon + olası key lookup.

Yeniden yazım
SELECT OrderId, Status, TenantId, CreatedAt
FROM Orders
WHERE CreatedAt >= '2026-01-01' AND CreatedAt < '2027-01-01';

İndeks
CREATE INDEX IX_Orders_CreatedAt ON Orders(CreatedAt) INCLUDE (Status, TenantId);

Plan: table scan → index seek + covering (lookup yok).
Risk: yazma yükü hafif artar; tarih aralığı yanlışsa boş küme. DROP yok.

KONTROL: + Sargable WHERE + Covering index + Prod silme önerisi yok

ROL: Test yazımında titiz bir mühendissin.
BAĞLAM: Dil/çatı = {DİL} (xUnit/NUnit veya eşdeğeri). Test edilecek = {KOD}.
GÖREV: Anlamlı birim testleri yaz.
KAPSAM:
- 1 mutlu yol
- 3 kenar durum (sınır değer, boş/null, çakışma)
- 1 hata yolu (beklenen exception + mesaj/koşul)
KURALLAR:
- Test adı davranışı anlatır: Method_State_Expected
- Arrange/Act/Assert net; her testte tek mantıksal iddia
- Mock’u abartma: sadece dış bağımlılık (IO/ağ/gateway) mock’lanır, saf mantık değil
- Deterministik: zaman/rastgelelik enjekte edilir
ÇIKTI: Derlenebilir test sınıfı + her testin 1 satır ‘neyi kanıtlıyor’ yorumu.

ÖRNEK DEĞİŞKEN
DİL: C#/xUnit · KOD: PaymentService.ChargeAsync (idempotency’li)

ÇIKTI (test adları + iskelet)
Charge_NewKey_WritesOnce            // ilk çağrı tek kayıt yazar
Charge_SameKey_SecondCallIsNoOp     // aynı anahtar ikinci kez yazmaz
Charge_EmptyKey_ThrowsValidation    // boş anahtar 400
Charge_ZeroAmount_ThrowsValidation  // sınır: 0 tutar reddedilir
Charge_UnknownGateway_ThrowsNotFound// resolver bilinmeyen sağlayıcı
Charge_GatewayTimeout_NoSecondWrite // hata yolu: timeout çift yazmaz

[Fact] public async Task Charge_SameKey_SecondCallIsNoOp() {
  // Arrange: gateway mock, aynı IdempotencyKey ile iki çağrı
  // Act:     ikinci ChargeAsync
  // Assert:  store.WriteCount == 1
}

KONTROL: + Ad davranışı anlatıyor + Sadece gateway mock’landı + Zaman/rastgelelik enjekte

ROL: Container güvenliği ve imaj optimizasyonu uzmanısın.
GÖREV: Verilen Dockerfile’ı incele ve düzelt.
İNCELE:
- Root kullanıcı, gereksiz katman, cache kırılması (COPY sırası)
- Sır (secret) imaja gömme, ARG ile sızıntı
- Imaj boyutu (multi-stage, .dockerignore, base seçimi)
- Reproducibility (pinlenmiş sürüm)
ÇIKTI:
1) Bulgular: önem sırası + neden
2) Düzeltilmiş Dockerfile (multi-stage, non-root USER, restore→build sırası, runtime base)
3) .dockerignore önerisi
4) 5 satır gerekçe (her düzeltme neden)
KISIT: Exploit, container escape veya güvenlik bypass tekniği YAZMA. Sır yönetimini runtime/secret store’a bırak. Dosya:

{DOCKERFILE}

ÖRNEK DEĞİŞKEN
DOCKERFILE: tek stage, root, COPY . ., ARG içinde bağlantı cümlesi

ÇIKTI
Bulgular
- Yüksek: root çalışıyor (USER yok)
- Yüksek: secret ARG’da → imaj katmanında kalır
- Orta: COPY . . restore’dan önce → cache her build kırılıyor
- Orta: tek stage → SDK imajı şişkin

Düzeltme (özet)
FROM sdk AS build → csproj kopyala → restore → kaynak → publish
FROM aspnet AS runtime → COPY --from=build → USER app
Secret: runtime env / secret store, imaja gömme.

.dockerignore: bin/, obj/, .git/, *.user
Gerekçe: cache ısınır, imaj küçülür, süreç root değil, sır katmanda kalmaz, sürümler pinli.

KONTROL: + Multi-stage + non-root + Secret imajdan çıktı + Exploit/bypass yok

ROL: Temiz PR yazan bir mühendissin; inceleyicinin işini kolaylaştırıyorsun.
BAĞLAM: Diff özeti = {ÖZET}. (Varsa ilgili issue = {ISSUE}.)
GÖREV: Pull request açıklaması yaz (Türkçe).
ŞABLON:
1) Amaç: hangi problem, neden şimdi (1-2 cümle)
2) Yaklaşım: nasıl çözüldü, alternatifler neden elenmedi/elendi
3) Değişiklikler: madde madde (dosya/alan bazında, kısa)
4) Test: nasıl doğrulandı (birim/manuel adım), kanıt
5) Risk & etki: geriye dönük uyum, migration, feature flag
6) Rollback: nasıl geri alınır
KISIT: ≤200 sözcük gövde. ‘Refaktör yaptım / düzelttim’ gibi içi boş cümle yasak; somut ol. Ekran görüntüsü gereken yeri ‘[ekran]’ ile işaretle.

ÖRNEK DEĞİŞKEN
ÖZET: ChargeAsync’e idempotency anahtarı + unique index eklendi

ÇIKTI
Amaç: Timeout sonrası retry aynı ödemeyi iki kez yazıyordu; çift tahsili önlemek için.
Yaklaşım: IdempotencyKey unique index; ikinci çağrı kayıtlı sonucu döner (no-op). Alternatif olarak dağıtık kilit düşünüldü, tek DB’de gereksiz karmaşık olduğu için elendi.
Değişiklikler: ChargeRequest’e key alanı · PaymentService no-op dalı · migration (unique index) · alarm kuralı.
Test: yeni anahtar yazar, aynı anahtar no-op, boş anahtar 400 (xUnit). Manuel: iki hızlı istek → tek kayıt [ekran].
Risk: eski istemci anahtar göndermezse eski davranış; flag ile korunuyor.
Rollback: flag kapat; index kalabilir.

KONTROL: + Somut, ‘refaktör yaptım’ yok + Test kanıtı var + Rollback net

ROL: Regex ve girdi doğrulama uzmanısın (.NET motoru).
BAĞLAM: İhtiyaç = {İHTİYAÇ}. Kullanım yeri = {NEREDE} (ör. form doğrulama).
GÖREV: Güvenli, dar kapsamlı bir regex üret.
ÇIKTI:
1) Regex (tek satır, .NET uyumlu) + anchored (^...$)
2) 5 eşleşen örnek
3) 5 eşleşmeyen örnek (yakın-ama-yanlış olanları seç)
4) Satır satır açıklama (her grup ne yapar)
5) ReDoS notu: iç içe niceleyici / katastrofik backtracking var mı, nasıl kaçınıldı
6) Alternatif: regex yerine daha iyi bir yol varsa (ör. int.TryParse) söyle
KISIT: Zararlı payload, bypass veya güvenlik açığı üretme. Aşırı geniş ‘.*’ deseninden kaçın.

ÖRNEK DEĞİŞKEN
İHTİYAÇ: TR sipariş no — ‘ORD-’ + 8 rakam · NEREDE: form doğrulama

ÇIKTI
Regex: ^ORD-[0-9]{8}$

Eşleşen: ORD-00000001 · ORD-20260914 · ORD-10000000 · ORD-99999999 · ORD-00420042
Eşleşmeyen: ord-00000001 (küçük harf) · ORD-123 (kısa) · ORD-123456789 (uzun) · ORD_00000001 (alt çizgi) · ORD-12AB5678 (harf)

Açıklama: ^…$ tam satır · ‘ORD-’ sabit önek · [0-9]{8} tam 8 rakam.
ReDoS: iç içe niceleyici yok, sabit uzunluk → katastrofik backtracking riski yok.
Alternatif: önek kontrolü + Substring + int.TryParse da yeterli, regex şart değil.

KONTROL: + Anchored, dar kapsam + ReDoS güvenli + Zararlı payload yok

ROL: Güvenli kod incelemecisisin (defansif bakış).
GÖREV: Verilen kodu güvenlik + bakım açısından incele.
BAK:
- Injection (SQL/komut), girdi doğrulama
- Hassas veri: log/exception’da PII/kart/secret sızıntısı
- AuthN/AuthZ boşluğu, IDOR
- Hata yönetimi: ham exception’ın kullanıcıya dönmesi
- Bakım: bağımlılık, ölü kod, sıkı bağ
ÇIKTI:
1) Bulgular önem sırasıyla (Kritik/Yüksek/Orta/Düşük) + dosya/satır tahmini
2) Her bulgu için güvenli ALTERNATİF (düzeltme yönü, tek örnek satır)
3) 1 hızlı kazanç önerisi
KISIT: Exploit PoC, payload, saldırı adımı veya bypass YAZMA — sadece savunma tarafı. Kod:

{KOD}

ÖRNEK DEĞİŞKEN
KOD: log’a ham request body + string birleştirmeli SQL + ham exception dönüşü

ÇIKTI
Bulgular
- Kritik: string birleştirmeli SQL → injection riski (repo katmanı)
- Yüksek: ham request body log’da → PII/kart sızıntısı
- Orta: exception mesajı olduğu gibi client’a dönüyor → bilgi ifşası
- Düşük: doğrulama controller’a dağılmış → bakım zorluğu

Alternatif
- Parametreli sorgu / ORM parametresi (birleştirme yok)
- Log’a sadece orderId + status; body maskeli
- Client’a genel hata, detay sunucu log’unda (correlation id)

Hızlı kazanç: global exception handler + input validation attribute.

KONTROL: + Önem sıralı bulgular + Savunma yönü verildi + Exploit/payload/bypass yok

Kod Promptları

Nasıl kullanılır?