Hedefli tuning — instruction, tool access, memory üçgeni

Domain 4.3 — eval sonucuna göre hedefli müdahale. Yanlış kanala tuning = boşa efor + yeni hatalar.

Tuning kanalı haritası (RCA → kanal)

Kök neden	Birinci kanal	İkinci kanal	Üçüncü kanal
Reasoning error	Instruction revize	Plan template	Model değişikliği (son çare)
Tool misuse	Tool access daralt	Tool kullanım örneği	Tool’u kaldır
Context/env issue	Env constraint	Memory scope	System of record

Custom instructions revizyonu — pratik teknikler

.github/copilot-instructions.md’i tune etmenin somut yolları:

1. Spesifik > genel

❌ “İyi kod yaz” ✅ “All public API functions must have JSDoc with @param and @returns”

2. Failure pattern’lerini belgele

Her tekrarlayan hata için instruction’a örnek ekle:

## Common failure patterns to avoid

### Don't use `Promise.all` for serial operations
WRONG:
```ts
await Promise.all(items.map(item => process(item)));
// ↑ Parallel — race condition if items depend on each other

RIGHT:

for (const item of items) {
  await process(item);
}

### 3. Kuralları kategorize et
```markdown
## Code style (auto-fail PR)
- TypeScript strict mode
- No `any` type without comment

## Architecture (review concern)
- New endpoints follow REST conventions
- Database access only through repository pattern

## Security (block-by-default)
- No hardcoded secrets
- All user input validated

4. Constraint’lerin önceliğini açıkla

## Priority order (when constraints conflict)
1. Security > Correctness > Performance > Style
2. Backward compat > New features (unless major version)

5. Test pattern’leri zorunlu kıl

## Test requirements
- Every new public function has a unit test
- Test name pattern: `should <behavior> when <condition>`
- Use vitest, not jest

Tool access daralma stratejileri

Domain 4.3 bullet: “Refine tool usage and tool access”.

Strateji 1: Scope daralt

# Önce
allow_list:
  - "github-remote:*"   # tüm GitHub MCP tool'ları

# Sonra (daraltıldı)
allow_list:
  - "github-remote:get_issue"
  - "github-remote:get_pull_request"
  - "github-remote:list_pull_requests"
  - "github-remote:create_pull_request_comment"
  # Diğerleri default-deny

Strateji 2: Risky tool’u kaldır

Tool misuse 5 kez tekrar etti, neden? Tool muhtemelen agent için karmaşık. Seçenek:

• Daha basit tool ile değiştir (örn. gh-cli yerine gh-api direct)
• Tool’u kaldır + insan yap
• Tool’u wrapper ile sarmala (validation katmanı ekle)

Strateji 3: Validation katmanı

// Direct tool çağrı yerine
await mcp.call("github-remote:create_pr", { ... });

// Validation wrapper
async function safeCallPR(args) {
  if (!args.title || args.title.length > 100) {
    throw new Error("Invalid PR title");
  }
  if (!args.body || args.body.length < 50) {
    throw new Error("PR body too short — describe the change");
  }
  return await mcp.call("github-remote:create_pr", args);
}

Agent direct çağrı yerine wrapper kullanır. Bad input early fail.

Strateji 4: Tool kullanım örneği instruction’a

## Tool usage examples

### Creating a PR
ALWAYS include:
- title: descriptive, < 70 chars
- body: includes "## Summary", "## Test plan", "## Risk"
- base: usually main
- head: feature branch

Example:
```ts
await mcp.call("github-remote:create_pull_request", {
  title: "fix: handle null user in auth flow",
  body: "## Summary\n- Adds null check\n\n## Test plan\n- Unit tests pass\n\n## Risk\n- Low — edge case",
  base: "main",
  head: "fix/auth-null"
});

## Memory tuning

Domain 4.3 bullet: "Refine memory usage".

### Scope daralt
```yaml
memory:
  scope:
    include:
      - "ekip kod stili kararları"
      - "aktif sprint kararları"
    exclude:
      - "6 aydan eski debug notları"
      - "kapanan PR yorumları"

Expiration kuralları sıkılaştır

memory:
  rules:
    - pattern: "debug_*"
      ttl_days: 7
    - pattern: "team_pref_*"
      ttl_days: 365
    - pattern: "incident_*"
      ttl_days: 90

Reset trigger’ı ekle

memory:
  reset_on:
    - "new_unrelated_task"   # yeni context
    - "manual_reset"
    - "ttl_expired"

Tuning döngüsü

[1] Eval sinyali fail (CodeQL, test, review)
  ↓
[2] RCA (logs, trace, plan, output) → kategori
  ↓
[3] Kanal seç (instruction / tool / memory)
  ↓
[4] Spesifik tuning uygula
  ↓
[5] Aynı eval senaryosu retry
  ↓
[6] Geçti mi? Evet → kapat. Hayır → kategoriyi yeniden değerlendir

Bu döngü kapatılmalı (closed loop). Aynı hata için 3+ tur açık kalmışsa muhtemelen kategori yanlış teşhis edilmiş.

Yargısal: tuning ne zaman durur?

Sinyal	Anlam
Aynı hata 3 turda çözülmüyor	Kategori yanlış / kök neden daha derin
Tuning her hatayı çözüyor ama yenisi geliyor	Genel design sorunu, tek-tek tuning yetmiyor
Tüm constraint’ler eklenince agent çok yavaş	Over-constraint; gevşet
Agent sadece basit görevi yapabiliyor	Aşırı daraltma; geri al

Mini quiz — Tuning (3 soru)

Aynı tool misuse 5 kez tekrar etti. En etkili tuning kanalı?

1. Daha güçlü model bağla
2. Tool access daralt + tool kullanım örneği instruction'a ekle
3. Memory'yi sıfırla
4. Agent'ı sil

Kontrol et

Memory tuning'in 3 ana ekseni hangisidir?

1. Scope + expiration + reset trigger
2. Renk + format + dil
3. Boyut + maliyet + hız
4. Encrypted + signed + auth

Kontrol et

Tuning döngüsünün 'kapanması' (closed loop) ne anlama gelir?

1. Aynı eval senaryosu retry edildiğinde hata tekrar etmez
2. Tuning hiç durmaz
3. Sadece test geçer
4. Sadece insan onayı

Kontrol et

Sırada ne var?

Domain 5 — Multi-agent koordinasyon modülüne geçiyoruz. 2 ek ders: orchestration + isolation derinleştirme + lifecycle yönetimi.