Bölüm 22: 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 (in_review veya draft 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 kartında tür bilgisi badge olarak görünür:

Target Type	Badge Etiketi	Açıklama
`policy`	Policy Change	Politika kuralı değişikliği talebi
`routing`	Routing Change	Yönlendirme kuralı değişikliği talebi
`acl`	ACL Change	Erişim kontrol listesi değişikliği talebi
`cost_limit`	Cost Limit Increase	Kullanıcı maliyet limiti artırım talebi

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 → (revise ile draft'a döner)
herhangi bir non-terminal durum → cancelled

Durum	Anlamı
`draft`	Talep oluşturulmuş ama henüz incelemeye sunulmamış
`in_review`	Talep incelemeye sunulmuş, onay veya red bekliyor
`approved`	Talep onaylanmış, henüz aktive edilmemiş
`rejected`	Talep reddedilmiş, revize edilerek tekrar draft'a döndürülebilir
`active`	Talep aktive edilmiş, değişiklik canlıda uygulanmış
`deprecated`	Aktive edilmiş değişiklik yürürlükten kaldırılmış
`cancelled`	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: talebi oluşturan kişi (author) kendi talebini onaylayamaz veya reddedemez. Sistem bunu engeller ve hata döner. Bu kural yalnızca in_review durumundaki approve ve reject geçişlerinde uygulanır; comment, submit, cancel gibi işlemler herkes tarafından yapılabilir.

Approval Inbox Arayüzü¶

Sayfa Başlığı: "Approval Inbox" Alt Başlık: "Review and approve pending governance changes" Sağ Üst: Bekleyen talep sayısını gösteren turuncu badge (X Pending)

Sayfa iki bölümden oluşur:

Pending Approvals Bölümü¶

Durumu in_review veya draft olan tüm talepler burada kart olarak listelenir. Her kart şu alanları içerir:

Sol Kenar Çubuğu: Turuncu renkli dikey çizgi.
Başlık Satırı: Talep başlığı (kalın), target type badge'i (Cost Limit Increase / Policy Change / ACL Change), ve varsa ticket referansı (monospace chip).
Talep Sahibi Bilgisi: "Requested by () · ".
Durum Badge'i: Sağ üstte "Pending" yazan turuncu, nabız efekti veren badge.
Reason Bloğu: Talep nedeninin yazdığı metin alanı. Üstünde "REASON" etiketi.
Cost Limit Detayları (yalnızca cost_limit türünde): İki sütunlu grid içinde talep edilen limitler:
Daily Token Limit (ör. "1.5M tokens")
Monthly Token Limit
Monthly Cost Limit (ör. "$500.00")
Daily Prompt Limit
Monthly Prompt Limit
Target Bloğu (cost_limit dışındaki türlerde): Target ID (monospace) ve Tenant ID bilgisi.
Yorum Zinciri (Comments): Eğer talebe yorum eklenmişse, her yorum için aktör adı, tarih ve not metni gösterilir. Üstünde "COMMENTS (X)" etiketi.
Aksiyon Butonları:
Approve: Yeşil buton. approve geçişini tetikler, otomatik not ekler: "Approved via Admin Panel".
Reject: Gri buton, kırmızı hover efekti. reject geçişini tetikler, not: "Rejected via Admin Panel".

Sağ üstte Refresh butonu tüm listeyi yeniden çeker.

Boş durumda: "No Pending Approvals" başlıklı empty state bileşeni, "All policy change requests have been reviewed..." açıklamasıyla görüntülenir.

Recently Reviewed Bölümü¶

Durumu approved, rejected, active, deprecated veya cancelled olan taleplerden en son güncellenen 10 tanesi burada liste satırı olarak gösterilir. Her satır:

Durum İkonu: Sol tarafta renkli kutu içinde:
Yeşil arka plan: approved, active
Kırmızı arka plan: rejected
Gri arka plan: cancelled, deprecated
Başlık Satırı: Talep başlığı, durum badge'i (Approved, Rejected, Cancelled, Active, Deprecated), ve target type badge'i.
Alt Satır: Talep sahibi, inceleyen kişi ("Reviewed by "), güncellenme tarihi, ve varsa son aksiyon notu (italik, tırnak içinde).

Boş durumda: "No Reviewed Requests" empty state bileşeni.

Kullanıcı Tarafından Cost Limit Artırım Talebi¶

Son kullanıcılar, kendi profil sayfalarından (/user/profile) maliyet limitlerini artırma talebinde bulunabilir. "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 prompt limiti
Monthly Prompts	Number	Hayır	Talep edilen aylık prompt limiti

Bu işlem bir cost_limit türünde onay talebi oluşturur ve otomatik olarak in_review durumuna geçer. Admin tarafından onaylandığında talep otomatik olarak active durumuna geçer ve yeni limitler kullanıcının maliyet yapılandırmasına birleştirilir.

Yönlendirme ve ACL Kurallarında Onay Zorunluluğu¶

Routing (RoutingRule) ve ACL (ACLRule) kayıtları, X-Approval-Request-ID HTTP header'ı ile onay talebine bağlanabilir. Bu kayıtlar iki onay alanı taşır:

approval_ref: İlişkili onay talebinin referansı.
approved_by: Onaylayan kişinin kimliği.

Bu mekanizma, kritik yönlendirme ve erişim değişikliklerinin onay akışından geçmesini zorunlu kılar.

Compliance ve Denetim Bağlamı¶

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

Her talebin yaşam döngüsü (oluşturan, inceleyen, tarih damgaları) kalıcı olarak saklanır.
Yorum zinciri, karar gerekçelerinin belgelenmesini sağlar.
Ticket referansı (ticket_ref), kurum内部的 change management sistemleriyle ilişkilendirme imkanı sunar.
RBAC: SecurityAuditor rolü onay taleplerini okuyabilir; TenantAdmin rolü okuma ve yazma (geçiş) yapabilir.

API Uç Noktaları¶

Method	Path	Açıklama
`GET`	`/admin/api/approvals/requests`	Tüm talepleri listeler. `?tenant=` ile filtreleme.
`POST`	`/admin/api/approvals/requests`	Yeni talep oluşturur. Body: `ChangeRequest`.
`POST`	`/admin/api/approvals/requests/{id}/transition`	Talep üzerinde durum geçişi uygular. Body: `{ action, actor, note }`.
`POST`	`/api/user/limit-request`	Kullanıcı tarafından cost limit artırım talebi.

Tüm admin uç noktaları approval_workflow feature flag kontrolüne tabidir. Enterprise plan aktif değilse HTTP 402 döner.