Bölüm 28: Approval Workflow ve Compliance

Genel Bakış

Approval Workflow, kritik politika ve yapılandırma değişikliklerinin tek kişi tarafından değil, maker-checker (oluşturan-onaylayan) modeliyle kontrollü biçimde yürütülmesini sağlayan yönetişim katmanıdır. Bu özellik Enterprise plan lisansı gerektirir; diğer planlarda sidebar'da görünmez.

Sayfaya erişim: Sidebar → Approvals (/admin/approvals). Sidebar bağlantısının yanında bekleyen (Taslak veya Bekliyor durumundaki) talep sayısını gösteren turuncu bir badge görüntülenir ve bu sayı her 60 saniyede bir otomatik güncellenir.

Onay Talebi Türleri (Target Types)

Her onay talebi bir hedef türüne sahiptir. Talep satırında tür bilgisi badge olarak görünür:

Target Type	Badge Etiketi	Açıklama
policy	Politika Değişikliği	Politika kuralı değişikliği talebi
acl	ACL Değişikliği	Erişim kontrol listesi değişikliği talebi
cost_limit	Maliyet Limiti Artışı	Kullanıcı maliyet limiti artırım talebi
provider	Sağlayıcı Talebi	Kullanıcının self-servis formundan gönderdiği önerilen sağlayıcı kaydı
model_access	Geçici Model Erişimi	Belirli bir model için süreli geçici erişim talebi

Tabloda etiketi olmayan bir tür gelen talepte badge, türün ham adını gösterir.

Yaşam Döngüsü ve Durum Geçişleri

Bir onay talebi aşağıdaki durum makinesi boyunca ilerler:

draft → in_review → approved → active → deprecated
                    \→ rejected → (revize ile draft'a döner)
herhangi bir non-terminal durum → cancelled

Durum	Arayüz Etiketi	Anlamı
draft	Taslak	Talep oluşturulmuş ama henüz incelemeye sunulmamış
in_review	Bekliyor	Talep incelemeye sunulmuş, onay veya red bekliyor
approved	Onaylandı	Talep onaylanmış, henüz aktive edilmemiş
rejected	Reddedildi	Talep reddedilmiş, revize edilerek tekrar Taslak durumuna döndürülebilir
active	Aktif	Talep aktive edilmiş, değişiklik canlıda uygulanmış
deprecated	Kullanımdan Kaldırıldı	Aktive edilmiş değişiklik yürürlükten kaldırılmış
cancelled	İptal Edildi	Talep iptal edilmiş (terminal durum)

Terminal durumlar (deprecated, cancelled) üzerinden başka bir geçiş yapılamaz.

Maker-Checker Zorunluluğu

Onay ve red işlemleri maker-checker kuralına tabidir ve bu kural sunucu tarafında, admin API üzerinden atlanamaz hale getirilmiştir (#1648):

• Talebi oluşturan kişi (author) kendi talebini onaylayamaz veya reddedemez; sistem bunu engeller. Admin panelinden açılan bir talep, oturum açmış adminin kendi adına oluşturduğu bir Taslak'tır — approved veya active gibi başka bir durumla dosyalama ve başkası adına talep açma reddedilir.
• Her onay/red işlemi, oturum açmış adminin kimliği altında kayda geçer (eski sürümlerde yalnızca "admin" yazıyordu).
• Talep yalnızca kendi içeriğiyle saklanır; istemcinin gönderdiği sahte inceleyen, yorum zinciri veya tarih alanları sunucu tarafından atılır.
• Limit artırımı, sağlayıcı kaydı ve geçici model erişimi değişiklikleri yalnızca onay (approve) eylemiyle uygulanır; onaylanan bir sağlayıcı talebi mevcut bir sağlayıcının üzerine yazamaz.
• Onaylanan bir değişiklik uygulanamadıysa talep Onaylandı olarak kalır ve apply_failed olarak kayda geçer; sonraki bir yorumla veya el ile aktive etmeyle tekrar denenmez — talep iptal edilip yeniden açılır.
• Otomasyonlar artık talebi doğrudan in_review olarak açamaz; önce Taslak oluşturup sonra incelemeye sunmaları gerekir.
• Limit, sağlayıcı ve model erişimi taleplerini yalnızca ilgili kullanıcı kendi adına açabilir; bir admin bu talepleri kullanıcılar adına dosyalayamaz.

Tenant Sınırı ve Rol Erişimi

Approvals, TenantAdmin ve SecurityAuditor rolleri için tenant sınırına tabidir (#1318):

• Her iki rol de yalnızca kendi tenant'ının onay kuyruğunu görür; başka bir tenant adı filtre olarak verilirse istek 403 ile reddedilir.
• Başka bir tenant'ın talebi, var olmayan bir talep ile aynı şekilde yanıtlanır; var olan bir talep kimliğini kullanarak yeni talep oluşturma girişimi, üzerine yazmak yerine 409 ile reddedilir.
• Her çapraz tenant erişim reddi Audit Log'a yazılır ("Refused cross-tenant access to Approval …") ve Bölüm 25'teki Audit Log ekranından izlenebilir.
• Admin ve PolicyAdmin rolleri istediği tenant'a göre filtreleyebilir; SecurityAuditor yalnızca okuma, TenantAdmin kendi tenant'ında okuma ve geçiş (yazma) yetkisine sahiptir. Admin hesabının kendi tenant'ı olmadığından, tenant kapsamlı bir rol varsayılan tenant'a sabitlenir.

Onay Kutusu Arayüzü

Sayfa Üst Bilgisi: Eyebrow "Yönetişim", başlık "Onay Kutusu", açıklama "Bekleyen yönetişim değişikliklerini inceleyin ve onaylayın". Sağ üstte bekleyen talep sayısını gösteren turuncu badge ("{count} Bekliyor") bulunur.

Sayfa üç bölümden oluşur: filtre çubuğu, onay talepleri tablosu ve satır tıklanınca açılan detay bölgesi.

Filtre Çubuğu

• Durum Filtresi (Dropdown): Dört seçenek — Bekleyen (Taslak + Bekliyor), Onaylanan (Onaylandı + Aktif), Reddedilen (Reddedildi) ve Tümü. Varsayılan seçim Bekleyen'dir; Tümü seçildiğinde istemci tarafı filtreleme uygulanmaz.
• Arama Kutusu: "Kullanıcı veya başlık ara..." yer tutucusuyla; talep sahibinin adı/kimliği veya talep başlığı üzerinden arar.
• Refresh: Listeyi yeniden çeker. Filtre, arama terimi veya sayfa boyutu değiştiğinde liste otomatik olarak ilk sayfaya döner ve açık detay satırı kapanır.

Onay Talepleri Tablosu

Talepler, en yeni oluşturulan en üstte olacak şekilde sıralanır. Sütunlar:

• Kullanıcı: Talebi açan kişinin adı (yoksaa kimliği); adı biliniyorsa yanında monospace kimlik.
• Başlık: Talep başlığı ve target type badge'i (ör. "Maliyet Limiti Artışı", "Sağlayıcı Talebi").
• Talep Edildi: Oluşturulma tarihi.
• Durum: Durum badge'i — Taslak/Bekliyor turuncu, Onaylandı/Aktif yeşil, Reddedildi kırmızı, İptal Edildi/Kullanımdan Kaldırıldı gri.
• Genişletme Oku: Satır tıklanınca detay bölgesi açılır/kapanır.

Başlığın sağında toplam "{count} talep" badge'i, tablonun altında sayfalama (varsayılan sayfa boyutu 20; 10/20/50/100 seçenekleri) bulunur. Boş durumda "Talep Yok" başlıklı ve "Seçili filtreyle eşleşen onay talebi yok." açıklamalı bir empty state görüntülenir.

Satır Detayı

Satır tıklanınca açılan bölgede, talep türüne göre:

• Gerekçe: Talebin nedeninin yazdığı metin bloğu.
• Talep Edilen Limitler (yalnızca cost_limit): İki sütunlu grid içinde Günlük Token Limiti, Aylık Token Limiti ("{n} token"), Aylık Maliyet Limiti ("$…"), Günlük İstek Limiti ve Aylık İstek Limiti ("{n} istek"). Yalnızca talepte belirtilen alanlar gösterilir.
• Önerilen Sağlayıcı (yalnızca provider): Sağlayıcı ID, Temel URL, API Formatı (OpenAI / Anthropic / Google), Kimlik Doğrulama Stili (Bearer / API key header / Query param) ve varsa Chat Yolu alanları; altında talep edilen Modeller ve Model Desenleri monospace chip'leri.
• Talep Edilen Erişim (yalnızca model_access): Model, Sağlayıcı ve Süre ("{n} saat") alanları.
• Hedef Bloğu (diğer türlerde): Target ID (monospace) ve Kiracı bilgisi.
• İnceleyen: Üzerinde işlem yapılmış taleplerde onay/red veren kişinin adı ve varsa son aksiyon notu (italik, tırnak içinde).
• Yorumlar ({count}): Talebe eklenmiş her yorum için aktör adı, tarih ve not metni.

Onayla / Reddet butonları yalnızca bekleyen (Taslak veya Bekliyor) taleplerde ve oturum salt-okunur modda değilken gösterilir. Onaylama "Yönetici Paneli üzerinden onaylandı", reddetme "Yönetici Paneli üzerinden reddedildi" notunu ekler; işlem sonrası liste otomatik yenilenir ve açık detay kapanır.

Kullanıcı Self-Servis Talepleri

Son kullanıcılar kendi profil sayfalarından (/user/profile) üç tür talep açabilir. Bu talepler admin API üzerinden değil, yalnızca ilgili kullanıcının kendisi tarafından dosyalanabilir (#1648) ve onaylanınca approve eylemiyle otomatik uygulanır.

Maliyet Limiti Artırımı (cost_limit)

"Request Increase" butonu ile açılan modal formda şu alanlar doldurulur:

Alan	Tür	Zorunlu	Açıklama
Reason	Textarea	Evet	Artırım talebinin gerekçesi
Daily Token Limit	Number	Hayır	Talep edilen günlük token limiti
Monthly Token Limit	Number	Hayır	Talep edilen aylık token limiti
Monthly Cost ($)	Number (step 0.01)	Hayır	Talep edilen aylık maliyet limiti
Daily Prompts	Number	Hayır	Talep edilen günlük istek limiti
Monthly Prompts	Number	Hayır	Talep edilen aylık istek limiti

Admin talebi onayladığında yeni limitler kullanıcının maliyet yapılandırmasına birleştirilir.

Sağlayıcı Talebi (provider)

Kullanıcı, self-servis "Request a Provider" formuyla önerilen bir sağlayıcı tanımı gönderir: Sağlayıcı ID, Temel URL, API Formatı, Kimlik Doğrulama Stili, isteğe bağlı Chat Yolu ve model/desen listeleri. Talep, onay kutusunda "Önerilen Sağlayıcı" önizlemesiyle listelenir; onaylandığında sağlayıcı kaydı oluşturulur — mevcut bir sağlayıcının üzerine yazılamaz.

Geçici Model Erişimi (model_access)

Kullanıcı, erişmek istediği modeli (zorunlu), sağlayıcıyı (isteğe bağlı) ve süreyi saat cinsinden (varsayılan 24) bir gerekçeyle birlikte talep eder. Onaylandığında erişim belirtilen süre boyunca geçerli olur.

Ajan Güncelleme Onayları ve Bayt Pinleme

Developer Tools → Agent updates ekranındaki ajan güncelleme onayları, imzalanmış yapının tam baytlarını pinler (#1279):

• Onay, yalnızca pinlediği baytlar için geçerlidir; gateway imajı her yükseltildiğinde baytlar değiştiğinden güncelleme için yeni bir onay gerekir.
• Baytlar değiştiyse eski onay askıya alınır ve panelde approval_stale olarak gösterilir; bu onayla güncelleme uygulanmaz.
• İmzalama, yalnızca imzalanmış baytlar pinlenmişse onayı yeniden bağlar. Ayrıntılar için Bölüm 24.

Compliance ve Denetim Bağlamı

Onay akışı, uyumluluk denetimlerinde aşağıdaki bilgileri sağlar:

• Her talebin yaşam döngüsü (oluşturan, onaylayan, tarih damgaları) kalıcı olarak saklanır; onay/red daima oturum açmış adminin kimliği altında kayda geçer (#1648).
• Yorum zinciri, karar gerekçelerinin belgelenmesini sağlar; ticket_ref alanı, kurum içi change management sistemleriyle ilişkilendirme imkanı sunar.
• Onay gerektiren değişiklik türleri: politika ve ACL kural değişiklikleri ile kullanıcı self-servis talepleri (maliyet limiti artırımı, sağlayıcı kaydı, geçici model erişimi). Limit, sağlayıcı ve model erişimi değişiklikleri yalnızca onay eylemiyle uygulanır; tek başına uygulama yolu yoktur.
• Çapraz tenant erişim reddleri dahil her reddi işlemi Audit Log'a yazılır (Bölüm 25); onay süreçleriyle ilişkili olaylar raporlarda da izlenebilir (Bölüm 27).
• RBAC: SecurityAuditor rolü onay taleplerini kendi tenant'ında okuyabilir; TenantAdmin rolü kendi tenant'ında okuma ve yazma (geçiş) yapabilir (#1318).

Kural Aç/Kapa Durumu ve Yükseltme Davranışı (#1479)

MIME, OCR ve path filter kurallarının açık/kapalı durumu artık yalnızca operatörün belirlediği değerdir: Erişim Yönetimi'nde (Bölüm 11) kurala atama yapmak, atamayı taşımak veya kaldırmak kuralın durumunu değiştirmez ve kapalı bir kural atandığında atamanın kural açılana kadar bir şey uygulamadığına dair uyarı verilir. Yükseltmede yalnızca ataması kalmadığı için otomatik kapatılmış kurallar geri açılır (atanana kadar kimseye uygulanmazlar); atamalıyken kapatılmış bir kural kapalı kalır. Bu bir yükseltme talimatı değil, denetim sırasında kural durumlarının değerlendirilmesi için bir davranış notudur.