Dava Takibinde Versiyonlama: Dilekçe Revizyonları

Dava takibinde versiyonlama, bir dilekçenin taslaktan mahkemeye sunulan hâline kadar geçirdiği her değişikliği adlandırılmış, tarihli ve gerekçeli sürümler olarak saklamaktır. Amaç, büronun her an "mahkemeye hangi metin gitti, son onaylı metin hangisi, hangi revizyon neden yapıldı" sorularına dakikalar içinde cevap verebilmesidir. Bunun için üç şey yeterlidir: tek bir sürüm adlandırma düzeni, her revizyonda kısa bir değişiklik notu ve sürümlerin dava dosyasındaki süre ve duruşma kayıtlarına bağlanması. Dilekçe metni belge sisteminizde, süre ise takvim ve tebligat kaydınızda yönetilir; ikisi birbirine bağlı olmadığında hatalar başlar.

Versiyonlama Nedir ve Dilekçe Dosyalarında Neden Gerekir?

Versiyonlama, yazılım dünyasından gelen bir kavram olsa da hukuk bürosundaki karşılığı çok somuttur. Bir dava dilekçesi, cevap dilekçesi, istinaf dilekçesi ya da icra aşamasındaki bir talep yazısı tek seferde yazılıp bitmez. Önce stajyer ya da avukat bir taslak hazırlar, ortak avukat metni gözden geçirir, müvekkil olgusal bir düzeltme ister, ekler eklenir ya da çıkarılır, sonunda da son hâl mahkemeye sunulur. Bu zincirde her halka ayrı bir dosya olarak kalırsa, büro farkında olmadan aynı davanın beş farklı metnini taşımaya başlar.

Sorun metinlerin çokluğu değil, hangisinin geçerli olduğunun belirsizliğidir. "dilekce_son.docx", "dilekce_son_son.docx" ve "dilekce_SON_duzeltilmis.docx" adlı üç dosya yan yana durduğunda, hangisinin mahkemeye gittiğini ancak dosyayı hazırlayan kişi hatırlar. O kişi izinliyse, büro değiştirmişse ya da aradan aylar geçmişse cevap kaybolur. Versiyonlama, bu bilgiyi kişinin hafızasından çıkarıp dosyanın kendisine yazar.

İkinci gerekçe sorumluluktur. Mesleki pratikte bir metnin hangi aşamada kim tarafından değiştirildiği, müvekkille yazışmada ya da büro içi bir değerlendirmede sık sık gündeme gelir. "Müvekkil bu talebi eklememizi istemedi" ya da "bu cümle ilk taslakta vardı, sonra çıkarıldı" gibi konuşmaların yazılı karşılığı, sürüm notlarında durur. Not yoksa tartışma hafıza ile yürür; not varsa tarih ve gerekçe ile yürür.

Üçüncü gerekçe süredir. Dilekçe revizyonu çoğu zaman bir süre baskısı altında yapılır: cevap dilekçesi süresi, istinaf süresi ya da bir ara karar gereği sunulacak beyan dilekçesi. Süre son güne yaklaştıkça revizyon sayısı artar, hata riski de artar. Hangi sürümün "sunuma hazır" olduğunu bilmek, son gün akşamı yapılan telaşlı bir yükleme ile sakin bir kontrol arasındaki farkı yaratır.

Son olarak, versiyonlama büyük bürolara özgü bir lüks değildir. Tek avukatlı bir büroda da müvekkile gönderilen taslak ile mahkemeye sunulan metin arasında fark olabilir. Düzen basit tutulursa, yani birkaç kural ve birkaç dakikalık alışkanlıkla, tek kişilik büro da sekiz kişilik büro da aynı güvenceye ulaşır. Bu yazıda önce günlük hayattaki karışıklıkları, sonra adlandırma düzenini, ardından adım adım uygulamayı ve süre ile ilişkisini ele alıyoruz.

Dilekçe Revizyonlarında Sık Görülen Karışıklıklar

Sorunu somutlaştırmak için bir senaryo düşünelim. Örneğin Ankara'da icra ağırlıklı çalışan bir avukat, bir alacak davasında müvekkil adına cevaba cevap niteliğinde bir beyan dilekçesi hazırlıyor. Stajyer ilk taslağı yazıyor ve e-posta ile gönderiyor. Avukat kendi bilgisayarında düzeltip aynı dosya adıyla kaydediyor. Müvekkil telefonda iki olgu düzeltmesi istiyor; sekreter bunları ayrı bir kopyada işliyor. Son gün öncesi akşam, sekreter UYAP'a yüklenecek dosyayı seçerken elinde üç farklı "son" metin var ve hiçbiri diğerlerinin üzerine yazılmamış.

Bu senaryo uydurma bir felaket hikâyesi değil, her büronun bir şekilde yaşadığı bir durumdur. Karışıklığın kaynağı kötü niyet ya da özensizlik değil, ortak bir düzenin olmamasıdır. Herkes kendi mantığına göre dosya adı veriyor, herkes kendi kopyasında çalışıyor ve hiçbir kopya diğerinin "ana" sürüm olduğunu bilmiyor.

Aynı dosya adı, farklı içerik

Dosya adı değişmeden içerik değiştiğinde, e-posta ekinde giden dosya ile sunucudaki dosya aynı görünür ama aynı değildir. Müvekkile gönderilen taslak ile mahkemeye sunulan metin arasındaki fark ancak iki dosya yan yana açılıp satır satır okunursa fark edilir. Bu, en sinsi karışıklık türüdür çünkü kimse bir şeylerin yanlış olduğunu düşünmez.

Not düşülmeyen değişiklikler

İkinci tür karışıklık, değişikliğin kendisinin değil gerekçesinin kaybolmasıdır. Bir talep sonucu bölümünden çıkarılmıştır ama neden çıkarıldığı yazılı değildir. Altı ay sonra dosyayı devralan avukat, o talebin unutulduğunu mu yoksa bilinçli olarak çıkarıldığını mı anlayamaz. Bilinçli bir karar unutulmuş gibi okunur ve gereksiz bir ek dilekçe ihtiyacı doğar.

Üçüncü tür, sunulan sürümün kayıt altına alınmamasıdır. Mahkemeye gönderilen metnin UYAP'taki hâli ile büronun kendi arşivindeki hâli arasında birebir eşleşme yoksa, itiraz ya da düzeltme gerektiğinde elinizde referans olacak bir "sunulan" kopya bulunmaz. Düzenli bir büro, sunum anında metnin dondurulmuş bir kopyasını ayırır ve bir daha değiştirmez.

Sürüm Adlandırma ve Klasör Düzeni

Etkili bir adlandırma düzeni üç özelliği taşır: herkesin aynı şekilde uygulayabileceği kadar basit olmalı, dosya adından tarih ve durum okunabilmeli, alfabetik sıralamada en yeni sürüm kolay bulunabilmelidir. Karmaşık kodlar kısa sürede bırakılır; bu yüzden düzeni küçük tutmak, kusursuz olmasından daha değerli bir hedeftir.

Pratik bir kalıp şöyle kurulabilir: önce esas numarası ya da büro içi dosya kodu, sonra belge türü, sonra tarih, sonra sürüm numarası ve durum. Tarihi "yıl-ay-gün" sırasıyla yazarsanız, dosyalar alfabetik sıralandığında kronolojik sıraya da girer. Sürüm numarası ise taslak aşamasında "t1, t2", sunum sonrası ise "s1, s2" gibi iki ayrı seri olarak tutulabilir. Böylece dosya adına bakan herkes metnin henüz taslak mı yoksa mahkemeye sunulmuş mu olduğunu anlar.

Klasör düzeni de aynı sadelikte kalmalıdır. Her dava dosyası için bir ana klasör, içinde belge türüne göre alt klasörler ve her belge türünün içinde "taslaklar" ile "sunulanlar" ayrımı yeterlidir. Taslaklar klasöründe istediğiniz kadar revizyon bulunabilir; sunulanlar klasöründe ise yalnız mahkemeye gerçekten gönderilmiş, değiştirilmeyen kopyalar durur. Bu ayrım, "hangisi gitti" sorusunun cevabını klasör adından verir.

Tablodaki dört durum çoğu büro için yeterlidir. Daha fazla durum eklemek cazip görünür ama her yeni durum, bir kişinin daha yanlış seçim yapma ihtimali demektir. Eğer bir durumun uygulamada fark yaratmadığını görürseniz, o durumu kaldırmak düzeni güçlendirir.

Adım Adım Dilekçe Revizyon Süreci

Kuralların yazılı olması yetmez; her revizyonun aynı sırayla ilerlemesi gerekir. Sıra, işin "iki dakikalık hâli" olarak düşünülmelidir: bir kez alışıldığında bir sürüm açmak, kopyalayıp yeni bir ad vermek kadar kısa sürer. Aşağıdaki akış, taslaktan sunuma kadar çoğu dilekçe için uygulanabilir.

1. Sürümü açın. Önceki sürümü kopyalayıp sürüm numarasını artırın; eski dosyayı yerinde bırakın, üzerine yazmayın.
2. Değişiklik notunu yazın. Neyin değiştiğini ve gerekçesini tek cümleyle belgenin başındaki not alanına ya da sürüm kaydına ekleyin.
3. Sorumluyu belirleyin. Metni kimin inceleyeceğini ve onay yetkisinin kimde olduğunu kayda geçirin.
4. Süreyi kontrol edin. Dilekçenin bağlı olduğu sürenin son gününü ve iç hedef tarihi dosya kaydında görün; onay bu tarihten önce tamamlanacak şekilde planlayın.
5. Onaylayın ve dondurun. Sorumlu avukat onay verdiğinde sürümü "onaylı" olarak işaretleyin; bu noktadan sonra metinde değişiklik yapılacaksa yeni sürüm açın.
6. Sunun ve kopyayı arşivleyin. Mahkemeye gönderilen dosyayı sunulanlar klasörüne aynen koyun, gönderim tarihini ve gönderen kişiyi kaydedin.

Bu akışın en çok atlanan adımı ikincisidir. Değişiklik notu yazmak, dilekçenin kendisini düzeltmek kadar önemli görünmediği için son dakikaya bırakılır ve sonunda hiç yazılmaz. Oysa not, bir cümleden uzun olmak zorunda değildir: "Faiz talebi başlangıç tarihi müvekkil bilgisine göre düzeltildi" gibi bir satır, aylar sonra büyük zaman kazandırır.

Altıncı adım da aynı derecede kritiktir. Mahkemeye gönderdiğiniz metnin birebir kopyasını saklamıyorsanız, sonraki her iş "hatırladığımız kadarıyla" yürür. Gönderim anında dosyayı ayırmak birkaç saniye alır; aksi hâlde sonradan fark çıkarsa bunu kanıtlayacak bir referansınız olmaz.

Kısa bir not örneği, bu akışın sürüm kaydında nasıl görüneceğini gösterir:

Belge: Beyan dilekçesi, sürüm t3 (varsayımsal örnek)
Değişiklik: Delil listesine bir ek belge eklendi, sonuç ve istem bölümü sadeleştirildi.
Gerekçe: Müvekkil yeni belgeyi büroya iletti.
Sorumlu: Dosya avukatı, onay bekliyor.
Süre bağlantısı: Dava kaydındaki ilgili süre görevine bağlı.

Dosyada Rol Dağılımı: Avukat, Sekreter, Stajyer ve Müvekkil

Versiyonlama bir yazılım ya da klasör meselesi olduğu kadar bir sorumluluk dağılımı meselesidir. Büroda aynı metne dokunan en az dört taraf vardır ve her birinin yetkisi farklı olmalıdır. Yetki sınırları net değilse, en yetkisiz kişinin yaptığı bir değişiklik fark edilmeden sunuma kadar gidebilir.

Stajyer ve yeni başlayan avukatlar çoğunlukla ilk taslağı hazırlar. Onların görevi taslak serisinde çalışmaktır; "onaylı" ya da "sunuldu" durumuna geçirme yetkisi onlarda olmamalıdır. Bu, güvensizlik değil iş akışı disiplinidir: onay noktası tek bir kişide toplandığında, sunulan metnin sorumlusu da net olur.

Sorumlu avukat ya da ortak, inceleme ve onay yetkisini taşır. Revizyonda gördüğü her değişikliğin gerekçesini okur, gerekirse yeni bir sürüm açılmasını ister. Sunum öncesi son kontrolde yalnız "onaylı" durumundaki sürüm dikkate alınır; başka bir dosya, ne kadar yeni görünürse görünsün, sunuma gitmez.

Sekreterin rolü çoğu büroda gönderim ve arşivleme işidir. Onaylı sürümü mahkemeye iletir, gönderim tarihini kaydeder, kopyayı sunulanlar klasörüne koyar. Bu işi yapan kişinin hangi dosyanın gönderileceğini kendisinin seçmemesi, yalnız "onaylı" etiketli sürümü alması gerekir. Böylece kritik anda yanlış dosyayı yükleme ihtimali ortadan kalkar.

Müvekkil ise düzeltme isteyen ve olgusal bilgiyi doğrulayan taraftır, ancak doğrudan dosya düzenleyen taraf değildir. Müvekkilin istediği her değişiklik, büro tarafından bir sürüm notuyla kayda geçirilmelidir. Müvekkilin telefonda söylediği bir düzeltmenin yazıya dökülmemesi, ileride "bunu ben istemedim" tartışmasının zeminini hazırlar. Müvekkile gönderilen taslağın hangi sürüm olduğunu belirtmek de aynı sebeple faydalıdır.

Süre ile Sürüm Arasındaki Bağ: Hukuki Çerçeve

Dilekçe revizyonlarının hukuki boyutu süreyle başlar. Bir dilekçe ne kadar iyi hazırlanırsa hazırlansın, süresi içinde sunulmadıysa değeri kalmaz. Bu yüzden versiyonlama düzeninin her sürümünü, bağlı olduğu sürenin kaydına bağlaması gerekir. Önce sürenin nasıl başladığını doğru bilmek gerekir.

Elektronik tebligat, muhatabın elektronik adresine ulaştığı tarihi izleyen beşinci günün sonunda tebliğ edilmiş sayılır (Tebligat Kanunu m.7/a). Tebligatı okumak ya da açmak bu başlangıcı değiştirmez; erken açmak süreyi öne çekmez, geç açmak da ertelemez. Muhatabın tebliğ için ayrıca bir onay vermesi de gerekmez. Revizyon planlamasında bu önemlidir: "tebligatı henüz açmadık, süre başlamadı" düşüncesiyle hazırlanan bir takvim, sürenin gerçekte çoktan işlemeye başladığı bir gerçekle karşılaşabilir.

Gün olarak belirlenen sürelerde tebliğ günü sayılmaz; hafta, ay ya da yıl olarak belirlenen sürelerde ise süre, başladığı güne karşılık gelen günde biter (HMK m.92). Resmî tatiller süreye dahildir. Yalnız son gün hafta sonuna ya da resmî tatile denk gelirse süre izleyen ilk iş günü mesai sonunda sona erer (HMK m.93). Arife yarım gün olsa da süreyi uzatmaz. Yazılı yargılamada cevap dilekçesi süresi iki hafta, istinaf süresi de iki haftadır; revizyon planı bu iki tarihten geriye doğru kurulmalıdır.

Adli tatil, her yıl 20 Temmuz ile 31 Ağustos arasındadır. Hukukta süreler adli tatilde durmaz; son günü tatile rastlayan süre, tatilin bittiği günden itibaren bir hafta uzar (HMK m.104). İdari yargıda bu uzama yedi gün (İYUK m.8/3), tutuksuz ceza işlerinde üç gündür (CMK m.331). İcra takip işlemlerinde ve tutuklu işlerde böyle bir uzama yoktur. Bu nedenle adli tatile denk gelen bir revizyon planında "tatil olduğu için acele yok" düşüncesi risklidir.

Sürüm düzenini bu çerçeveyle birleştirmenin pratik yolu şudur: her dilekçe sürümünün kaydında, bağlı olduğu sürenin son günü ve büronun kendi iç hedef tarihi görünsün. İç hedef tarih, resmî son günden en az bir iş günü önce olmalıdır. Revizyon sayısı arttıkça iç hedef tarih sabit kalmalı, yeni sürüm açmak hedefi öteye itmemelidir. Süre hesabını elle yapmak yerine hukuki süre hesaplama aracıyla kontrol etmek, tarih hatasını baştan eler.

Özel Durumlar ve İstisnalar

Standart akış çoğu durumu karşılar, ancak bazı durumlar özel dikkat ister. Bunların başında, sunulmuş bir dilekçenin sonradan düzeltilmesi ihtiyacı gelir. Mahkemeye sunulan bir metni kendi sistemimizde değiştirmek, mahkemedeki metni değiştirmez. Sunulmuş bir dilekçedeki eksik ya da hatalı kısmı düzeltmenin hangi yoldan mümkün olduğu, ilgili usul kanunundaki düzenlemelere ve davanın aşamasına bağlıdır. Bu yüzden sunum sonrası düzeltme, büronun kendi sürüm kaydında yeni bir sürüm olarak açılır ve ayrıca hukuki yolun uygunluğu değerlendirilir.

Karşı tarafa tebliğ edilmiş metinler

Bir dilekçe karşı tarafa tebliğ edildikten sonra, karşı tarafın o metne göre yazdığı cevap da dosyaya girer. Bu durumda büronun elindeki arşiv, hem sunulan hem de karşı tarafça cevaplanan sürümü açıkça göstermelidir. Sonraki bir dilekçede yapılacak atıflar, sunulan sürümün sayfa ve bölüm yapısına göre kurulacağı için, yeniden biçimlendirilmiş bir taslak üzerinden atıf yapmak hataya yol açar.

Aynı gün birden fazla revizyon

Sunum günü birden fazla sürüm çıkabilir. Bu durumda tarih tek başına yetmez; sürüm numarası ve saat bilgisi de kaydedilmelidir. Aksi hâlde aynı tarihli iki dosyadan hangisinin gittiği ancak dosya özelliklerine bakılarak anlaşılır, bu da güvenilir bir yöntem değildir.

Ekler ve dilekçe birlikte sürümlenir

Ek belge listesi, dilekçenin parçasıdır. Dilekçede "ek-3" olarak atıf yapılan belge, sonraki bir sürümde numarası değiştiyse, atıflar da güncellenmelidir. Bu yüzden ekler klasörünün de sürüme bağlı olması, hangi dilekçe sürümüyle hangi ek setinin gittiğinin kaydedilmesi gerekir. Müvekkilden gelen belgeler yeni bir sürüme neden oluyorsa, sürüm notunda ilgili ek açıkça belirtilmelidir.

Müvekkil onayı da özel bir noktadır. Her dilekçenin müvekkil onayına sunulması gerekmeyebilir, fakat olgusal beyanlar içeren, rakam ya da tarih bildiren metinlerde müvekkilin gördüğü sürüm kayda geçmelidir. Müvekkil onayladıktan sonra yapılan her değişiklik yeni bir onay turu gerektirebilir; bu karar sorumlu avukata aittir ve sürüm notunda yer almalıdır.

MÜHLET ile Revizyon ve Süre Takibini Birbirine Bağlamak

MÜHLET bir dilekçe yazım ya da belge sürüm aracı değildir; metinlerinizin sürümlerini büronun belge düzeninde tutmaya devam edersiniz. MÜHLET'in işi, dilekçe revizyonlarının dayandığı süre ve tebligat tarafını güvenceye almaktır. Revizyon planı için en kritik bilgi, "son gün ne zaman" sorusunun cevabıdır ve bu cevabın elle hesaplanmaması gerekir.

MÜHLET, avukatın kendi bilgisayarında kendi oturumuyla UETS'e düşen e-tebligatları tarayıcı eklentisiyle otomatik alır; şifre MÜHLET'e verilmez ve sunucular UETS'e bağlanmaz. Yapay zekâ tebligat analizi mahkemeyi, esas numarasını, tarafları ve tebligat türünü çıkarır; her çıktı bağımsız bir usul kuralı motoruyla doğrulanır, düşük güvende avukat onayı istenir. Böylece cevap dilekçesi ya da istinaf dilekçesi gibi revizyona konu olacak belge için hangi sürenin işlediği baştan netleşir.

Süreler Türk adli takvimine göre hesaplanır: adli tatil, resmî tatil ve hafta sonu düzeltmeleri hesaba katılır. Süre takibi özelliği, son güne kadar kademeli olarak e-posta, SMS ve uygulama ya da tarayıcı bildirimiyle hatırlatma yapar; bildirim sistemi bu hatırlatmaları ekibe dağıtır. Dava, müvekkil, duruşma ve görev yönetimiyle her revizyon aşaması için görev açabilir, rol bazlı yetkiyle ortak, avukat, sekreter ve stajyerin neyi görüp neyi yapabileceğini ayırabilirsiniz. Takvim senkronizasyonu ve iOS/Android uygulaması, hatırlatmaların ofis dışında da ulaşmasını sağlar. Veriler KVKK uyumlu şekilde Türkiye'de barındırılır; sistem tebligat kredisiyle çalışır ve ilk kullanımda ücretsiz deneme kredisi verilir. Ayrıntılar için fiyatlar sayfasına bakabilirsiniz.

Pratikte bu, şu anlama gelir: dilekçe sürümleri büronun belge sisteminde kalır, sürenin son günü ve iç hedef tarih ise MÜHLET'te dava kaydında durur. Revizyon sayısı ne olursa olsun, takvim sabittir ve son güne kadar hatırlatmalar işlemeye devam eder.

Sık Yapılan Hatalar ve Kontrol Listesi

Versiyonlama düzenini kuran bürolar bile belirli hatalara düşer. İlki, düzeni kurup uygulamamaktır: yazılı kurallar vardır ama acele zamanlarda herkes eski alışkanlığına döner. Bu durumun çaresi kuralı katılaştırmak değil, kuralı kolaylaştırmaktır. Yeni sürüm açmak bir tıklama kadar kolay değilse, insanlar eski dosyanın üzerine yazmaya devam eder.

İkinci hata, sürüm notunu zorunlu görmemektir. Not yazılmayan bir sürüm, adlandırma düzeni olsa bile, bilgi taşımaz. Notun kısa tutulması ve belge türüne göre sabit bir şablonla yazılması, yazma direncini düşürür. Üçüncü hata, süreyi dilekçeden ayrı düşünmektir: metin üzerinde haftalarca çalışılır, sürenin son günü ise yalnız bir kişinin ajandasında durur.

Dördüncü hata, onay ve gönderim yetkisini aynı kişide, hiçbir kontrol olmadan toplamaktır. Kişi hem metni yazıp hem onaylıyorsa, ikinci bir göz devre dışı kalır. Beşinci hata ise sunulan kopyayı arşivlememektir. Mahkemeye giden metnin birebir kopyası saklanmazsa, sonraki bir tartışmada büro kendi arşivini referans olarak gösteremez. Aşağıdaki liste, sunum öncesi son kontrolde kullanılabilir.

• ✓ Sunulacak dosya "onaylı" durumunda ve sürüm numarası kayıtla eşleşiyor.
• ✓ Son değişikliğin notu yazılmış, gerekçesi okunabilir.
• ✓ Dava kaydındaki sürenin son günü ve iç hedef tarih kontrol edildi.
• ✓ Ek belge listesi ve dilekçedeki ek atıfları birbiriyle uyumlu.
• ✓ Gönderim sonrası dosyanın aynen sunulanlar klasörüne kopyalanacağı belli.

Bu liste, düzenin sonunda bir güvenlik ağı olarak çalışır. Beş maddenin her birinin kontrolü bir iki dakikayı geçmez, ancak atlanan her madde, bir revizyonun yanlış metinle sunulması ihtimalini artırır. Listeyi büro içinde ortak bir yere koymak ve her sunum öncesi aynı kişinin gözden geçirmesini sağlamak, düzenin en ucuz ve en etkili parçasıdır.

Son bir not: versiyonlama düzeni, büro büyüdükçe ya da dosya türü değiştikçe yeniden gözden geçirilmelidir. Başlangıçta yeterli olan dört durum, sonradan fazla ya da az gelebilir. Düzenin kendisinin de sürüm notu olmalıdır; kuralı ne zaman değiştirdiğinizi kaydetmek, ekibe eski ve yeni uygulama arasındaki farkı anlatmanızı kolaylaştırır.

Bu yazı genel bilgilendirme amaçlıdır; somut olayınız için hukuki değerlendirme gerekir.

Sık Sorulan Sorular