HITL pratiği — anlamlı onay vs hız öldüren onay — GH-600 Hazırlık

Domain 6.2 son bullet: “Preserve execution velocity by minimizing approvals that do not materially reduce risk”. Sınavın imza teması — her hafta tekrar eden tek prensip.

Risk-azaltıcı onay testi

Her onay için sor:

“Bu onayı kaldırırsam, hangi kötü senaryolar gerçekleşir? Bu senaryolar gerçek mi, ve bu senaryoları onay olmadan engelleyecek başka mekanizma var mı?”

Cevaba göre karar:

Cevap	Karar
Kötü senaryo yok	Onayı kaldır
Kötü senaryo var ama başka gate (test, scan) engelliyor	Onayı kaldır
Kötü senaryo var, başka gate yok	Onayı tut
Kötü senaryo var, başka gate yetersiz	Tut + gate güçlendir

Hız öldüren onay örnekleri (kaldırılacaklar)

Onay	Neden kaldırılır
Lint fix PR için zorunlu insan review	Test gate + lint check yeterli (otomatik validate)
Markdown typo fix onayı	Reversible, low risk
Format/whitespace cleanup onayı	Otomatik formatter + test
Dependency patch version bump	Semver patch = backward compat; test gate yeterli
Test eklenmesi onayı	Pure addition, risk yok
Test file refactor onayı	Test’in kendisi gate
Code comment ekleme	Functional değişiklik yok
`.gitignore` ekleme	Build-time check yeterli
Renamed variable (mechanical)	Linter + test gate
Auto-generated docs update	Generator deterministic

Bu onayları zorunlu kılmak = saatlerce gereksiz review beklemek = agent değerini sıfırlamak.

Anlamlı onay örnekleri (tutulacaklar)

Onay	Neden tutulur
Production database migration	Yüksek operational + reversibility belirsiz
Müşteri verisi etkileyen aksiyon	Compliance high + irreversible
Public API breaking change	Müşteri etkisi geniş
IAM policy değişikliği	Security high
Major dependency bump	Breakage riski + uyumluluk
Yeni external service entegrasyonu	Güvenlik review gereği
Production secret rotation	Security + operational
Compliance log retention değişikliği	Yasal gereklilik
Yeni public endpoint	Surface area genişlemesi
Database schema destructive değişiklik	Data loss riski

Controlled path mekanizmaları

Domain 6.2 bullet: “Require explicit authorization or controlled paths for irreversible or compliance-sensitive changes”.

1. Environment protection rules

Settings → Environments → production → Protection rules
  ✓ Required reviewers: [oncall-lead, sec-team]
  ✓ Wait timer: 10 minutes (deploy başlamadan önce)
  ✓ Deployment branches: main only

Ne zaman: Prod deploy + database operasyonu + secret rotation.

2. CODEOWNERS

# .github/CODEOWNERS
/src/auth/**           @security-team
/src/billing/**        @finance-team @security-team
/db/migrations/**      @db-team @oncall
/.github/workflows/**  @devops-team

Ne zaman: Kritik dosya/dizinler için spesifik review. CODEOWNERS + “Require review from CODEOWNERS” branch protection = otomatik routing.

3. Required signed commits

Settings → Branches → main → Require signed commits ✓

Ne zaman: Compliance gereği commit author kanıtlanmalı (SOX, HIPAA, vb.).

4. Multi-reviewer (review thresholds)

Settings → Branches → main → Required approving reviews: 2

Ne zaman: Yüksek risk değişiklikler için “iki göz” kuralı (4-eyes principle).

5. Repository rulesets (organization seviyesi)

Modern alternatif — org-wide kural:

# Org seviyesinde
rulesets:
  - name: "prod branch protection"
    target: "branch"
    enforcement: "active"
    bypass_actors: []  # kimse bypass edemez
    conditions:
      ref_name:
        include: ["~DEFAULT_BRANCH"]
    rules:
      - type: pull_request
        parameters:
          required_approving_review_count: 2
          dismiss_stale_reviews_on_push: true
          required_review_thread_resolution: true

Onay sayısı kararı

Risk	Önerilen reviewer sayısı
Low risk + reversible	0 (auto-merge)
Low risk + irreversible	1
Med risk	1
High risk + reversible	1 (specialist)
High risk + irreversible	2 (cross-team)
Compliance-sensitive	2+ (specialist + compliance)

Çok reviewer = bottleneck. Çok az = miss riski. Risk-bazlı ata.

Yargısal: HITL süreç tasarımı

İyi HITL süreç özellikleri:

Hızlı — reviewer 24 saat içinde cevap verebilmeli (oncall rotation)
Bağlamlı — agent PR description’da net bağlam verir
Async-friendly — reviewer toplantı beklemez
Auditlanabilir — onay zaman damgalı + reviewer kimliği kayıtlı
Eskalasyon yolu — reviewer cevap vermezse sıradaki kim

Kötü HITL süreç:

Manuel email / Slack DM (audit zayıf)
Tek reviewer (bottleneck)
Toplantı zorunlu (asenkron değil)
Belirsiz onay süresi (PR günlerce beklemekte)

Sınav favorisi sorular

Soru 1: “Bu onay ‘risk-azaltıcı’ mı?” testi nasıl uygulanır? Cevap: “Bu onayı kaldırsam ne kötü gerçekleşir, ve başka gate engelliyor mu?” sorusu.

Soru 2: Prod deploy için hangi mekanizma? Cevap: Environment protection rules (required reviewers + wait timer

deployment branches).

Soru 3: Yüksek risk + irreversible için kaç reviewer? Cevap: 2+ cross-team, ideal olarak specialist + compliance.

Mini quiz — HITL & velocity (3 soru)

Sırada ne var?

6 domain’in tüm dersleri tamam. Modül 8 — Sınav günü: tam mock, Pearson VUE prosedürü, sertifika + LinkedIn.