Sözleşme sürüm yönetimi: v1/v2/v3 kaosunu bitirmek

Şimdi · Siz · tüm dosya

Dosyaya bir adlandırma şeması ve bir değişiklik kaydı kuruldu.

Kaosun kaynağı dosya adı değildir; ama dosya adı, kaosun ilk görünür belirtisidir. Aşağıya sözleşmenin adını, iki tarafın kısaltmasını ve beklediğiniz tur sayısını girin: araç tutarlı bir adlandırma şeması, o şemaya göre tur tur üretilmiş dosya adları ve doldurmaya hazır bir değişiklik akışı verir.

27 Ağustos 2026, 14:05 · MUV + KAR · tüm metin

v5 temiz nüsha, iki nüsha hâlinde ıslak imzayla imzalandı. m.4.2’deki teslim süresi masada el yazısıyla düzeltildi ve düzeltme her iki tarafça paraflandı.

İmza anı: hangi nüsha esas alındı

İmza, bir sürümü “esas metin” hâline getiren andır ve sürüm yönetiminde tek geri alınamaz adımdır. Buna rağmen çoğu dosyada imza anının kendisi hiç kayda geçmez: klasörde beş sürüm durur, imzalı tarama da oradadır, ama hangi dosyanın imzalandığı yalnız o gün masada olanların hafızasındadır. Aradan iki yıl geçtiğinde bu, cevabı olmayan bir soruya dönüşür.

Kaydın kendisi kısadır. Bir satır yeter, ama o satırın içinde şunlar bulunur:

• İmzalanan dosyanın tam adı — Sürüm numarası tek başına yetmez; aynı sürümün işaretli ve temiz nüshası vardır.
• Sayfa sayısı ve ek listesi — Sonradan eklenen bir ek, sayfa sayısı yazılmamışsa fark edilmez.
• Nüsha sayısı ve kimde kaldığı — Her tarafın elindeki nüsha, uyuşmazlıkta ayrı ayrı ibraz edilir.
• İmza türü — Islak imza mı, güvenli elektronik imza mı: ikisi aynı sonucu doğurur ama saklama biçimleri farklıdır.
• El yazısı düzeltmeler ve parafları — Onaylanmamış bir çıkıntı yok hükmündedir (HMK m.207); bu satır, sonradan “bu düzeltme ne zaman girdi” tartışmasını kapatır.
• İmzalayanların yetkisi — İmza sirküleri ya da vekâletnamenin tarihi de kayda geçer; yetki, imza kadar sürümlüdür.

İmzanın hukuki çerçevesi dar ve nettir. Yazılı şekilde yapılması öngörülen sözleşmelerde borç altına girenlerin imzalarının bulunması zorunludur (TBK m.14); imzanın borç altına girenin el yazısıyla atılması gerekir ve güvenli elektronik imza, el yazısıyla atılmış imzanın bütün hukuki sonuçlarını doğurur (TBK m.15). Usulüne göre güvenli elektronik imza ile oluşturulan elektronik veriler senet hükmündedir (HMK m.205). Elektronik imzanın teknik ve idari çerçevesi ise 5070 sayılı Elektronik İmza Kanunu’nda düzenlenmiştir.

Masada yapılan el yazısı düzeltmeler için kural tek cümledir: paraflanmayan düzeltme, yapılmamış sayılır. Senet metnindeki çıkıntı, ayrıca imza veya parafla onaylanmadıkça yok hükmündedir; kazıntı ve silinti de onaylanmamışsa senedin geçerliliğini tartışmalı hâle getirir (HMK m.207). Uygulamada sayfaların tek tek paraflanması da yaygındır — bu kanunen zorunlu değildir, sayfa değiştirme iddiasını zorlaştıran bir ispat kolaylığıdır.

26 Ağustos 2026, 23:40 · MUV · tüm metin

v5 temiz nüsha imzaya hazırlandı; v5 işaretli nüsha silinmeden ayrı adla arşive kondu.

Temiz nüsha ve işaretli nüsha

Bunlar aynı belgenin iki görünümü değil, iki ayrı belgedir ve iki ayrı işi yaparlar: temiz nüsha imzalanır, işaretli nüsha ispatlar. İmza gününde herkes temiz nüshaya bakar ve işaretli nüsha çoğu zaman o gece silinir; oysa iki yıl sonra sorulacak soruların neredeyse tamamının cevabı yalnız işaretli nüshadadır.

Elektronik ortamdaki veriler de belgedir (HMK m.199); yani işaretli bir nüsha, bir e-posta eki ya da bir müzakere notu, tanık beyanı gibi “ikinci sınıf” bir delil değildir. Daha da önemlisi, elde tutulan belgeyi mahkemeye sunmak bir yükümlülüktür (HMK m.219) ve belge sunulmadığında mahkeme, sunulmamasının sebeplerini araştırarak belgenin içeriği konusunda diğer tarafın beyanını kabul edebilir (HMK m.220).

Sonuç pratik ve serttir: “kaybettim” bir savunma değil, bir risktir. İşaretli nüshayı saklamak, kendi lehinize olabilecek bir delili saklamaktır; atmak ise karşı tarafın o belgenin içeriği hakkındaki iddiasını rahatlatır.

Tacirler bakımından bunun bir de somut yükümlülük tarafı var: alınan ticari mektuplar ve gönderilen ticari mektupların suretleri de saklanması zorunlu belgeler arasındadır ve saklama süresi on yıldır (TTK m.82). Sözleşme müzakeresinin e-posta trafiği, bu tanımın dışında kalmaz.

26 Ağustos 2026, 22:10 · MUV · m.12.3 · m.19.1 · m.24

37 izlenen değişiklik tek işlemde kabul edildi, 9 yorum silindi. İşaretli hâlin kopyası önceden alınmıştı.

İzlenen değişiklikleri kabul etmek

“Tümünü kabul et” bir biçimlendirme işlemi gibi görünür; oysa yaptığı şey, metnin nasıl bu hâle geldiğini gösteren tek katmanı silmektir. İşlem geri alınamaz: dosya kapandıktan sonra o katman ne geri gelir ne başka bir yerde yaşar. Kayıp da sessizdir — metin bozulmaz, hiçbir uyarı çıkmaz, yalnızca sözleşme birdenbire hiç müzakere edilmemiş gibi görünür.

İkinci satırda kaybolan şey bir sayı değil, bir bilgi: süreyi kimin, hangi turda uzattığı. Ödeme süresi sonradan tartışma konusu olduğunda cevabı istenen soru “sözleşmede kaç gün yazıyor” değildir — o zaten okunuyor. Soru, kırk beş günün nereden geldiğidir.

Doğru sıra üç adımdır ve ikisi kabul etmeden öncedir:

1. 1 İşaretli nüshayı ayrı adla kopyalayın. Aynı dosyanın üzerine kabul etmek, yedeği olan tek kopyayı harcamaktır. Ad zaten şemada var: aynı sürüm, durum alanı isaretli.
2. 2 Yorumları müzakere notuna aktarın. Yorum çoğu zaman kimin neyi NEDEN istediğini taşıyan tek kayıttır ve kabul işlemiyle birlikte gitmez — ama “yorumları temizle” ile gider. Aktarılan not, kayıt defterinin “ne oldu” sütununu doldurur.
3. 3 Kabulü temiz nüsha üzerinde yapın. Kabul edilmiş metin yeni bir dosyadır, eskisinin devamı değil. Bu yüzden adı da değişir: durum alanı temiz olur.

24 Ağustos 2026, 11:20 · KAR · m.19.1 — cezai şart

Cezai şartın üst sınırı yükseltildi; gerekçe olarak “teslim gecikmelerinin tekrarı” gösterildi.

Kim, hangi turda, hangi maddeye dokundu

Yukarıdaki iki işaret, bir sürüm numarasının asla taşıyamayacağı bir bilgi taşıyor: oranı yükselten taraf, aynı hamlede tazminat talep hakkını saklı tutan cümleyi de çıkarmış. Bu iki hareket birlikte okunduğunda cezai şartın ne olarak kararlaştırıldığı sorusuna dair somut bir iz kalır. “v4” bunun hiçbirini söylemez.

Müzakere geçmişinin hukuki değeri buradan gelir. Bir sözleşmenin türünün ve içeriğinin belirlenmesinde ve yorumlanmasında, tarafların yanlışlıkla veya gerçek amaçlarını gizlemek için kullandıkları sözcüklere bakılmaksızın gerçek ve örtülü iradeleri esas alınır (TBK m.19). Bir maddenin hangi turda, kimin talebiyle girdiği ya da çıkarıldığı, o iradeyi gösteren en somut kayıttır — ve çoğu zaman tek kayıttır.

Sözleşmeye konulan bütünlük kaydı (“bu sözleşme, taraflar arasındaki tüm mutabakatın yerine geçer”) bu kaydı işlevsiz kılmaz. Kayıt, önceki mutabakatları sözleşmenin dışında bırakır; sözleşmenin kendisini yorumlarken tarafların gerçek ve ortak iradesine başvurmayı engellemez. Yani müzakere geçmişi bir yedek sözleşme değildir ama bir anlam kaynağıdır.

Kaydın dördüncü sütunu — “ne oldu” — bu yüzden nötr yazılır ve yön bildirir: yükseltildi, çıkarıldı, daraltıldı, eklendi, karşı öneri getirildi. “Düzeltildi” ya da “güncellendi” gibi kelimeler kullanılmaz: ikisi de bir yön bildirmez ve iki yıl sonra hiçbir şey anlatmaz.

20 Ağustos 2026, 17:45 · KAR · 12 madde

3. tur açıldı: v4 işaretli nüsha karşı taraftan geldi. m.19 üçüncü kez açıldı, m.7 kapandı.

Tur: sürüm numarasının ölçemediği şey

Tur, müzakerenin birimidir: metnin bir taraftan diğerine geçip geri dönmesi. Sürüm ise dosyanın birimidir: bir metnin belirli bir andaki hâli. Tek bir turda birden çok sürüm doğabilir — iç revizyon, vergi ekibinin dönüşü, bir maddenin iki alternatifi — ama tersi olmaz. İkisini aynı sayıyla takip etmek, iki farklı şeyi tek bir cetvelle ölçmeye çalışmaktır.

Turun bir de ölçü tarafı var ve sürüm numarasının hiç veremediği bilgi budur: bir madde kaç turdur kapanmıyor? Üç turdur açık kalan madde, müzakerenin asıl konusudur; geri kalan her şey onun etrafında döner. Bu bilgi, tur kapanış kaydı tutulduğunda kendiliğinden ortaya çıkar.

Son sütun tek başına okunduğunda müzakerenin hikâyesini veriyor: m.7 birinci turda kapandı, m.12 ikinci turda, m.19 ise sona kadar açık kaldı. Dosyayı ilk kez açan bir meslektaş, beş sürümü okumadan nerede durulduğunu bu sütundan öğrenir.

17 Ağustos 2026, 09:15 · MUV · kayıt yok

Dosya adı v3’e çıkarıldı. Neyin değiştiği hiçbir yere yazılmadı.

Numara değil, değişiklik kaydı

Sürüm numarası bir sıra bilgisidir ve yalnız tek bir soruyu cevaplar: hangi dosya hangisinden sonra geldi. Bu, dosyaları klasörde dizmeye yeter; başka hiçbir işe yaramaz. “v3” hiçbir sorunun cevabı değildir. Numaralamayı kusursuz yapan bir ekip bile, bir yıl sonra “bu madde neden böyle” sorusunun karşısında beş dosyayı yan yana açıp gözle karşılaştırmak zorunda kalır.

Kayıt defterinin birimi dosya değil değişikliktir. Her satır tek bir hareketi anlatır ve dört sütun taşır:

Beşinci bir sütun isteğe bağlıdır ve çoğu zaman en değerlisidir: neden. Talebin gerekçesi (“önceki iki teslimde gecikme yaşandı”) müzakere sırasında herkesin bildiği ama hiçbir yere yazılmayan bilgidir; sözleşmenin yorumunda ise doğrudan işe yarar.

Kaydın hukuki ağırlığı, sözleşmenin sonradan değiştirilmesinde de kendini gösterir. Sözleşmelerin geçerliliği kural olarak hiçbir şekle bağlı değildir (TBK m.12); ancak kanunda yazılı şekilde yapılması öngörülen bir sözleşmenin değiştirilmesinde de yazılı şekle uyulması zorunludur (TBK m.13). Aynı madde, sözleşme metniyle çelişmeyen tamamlayıcı yan hükümleri bu kuralın dışında tutar. Yani “v3 ile v4 arasında sözlü olarak şuna karar vermiştik” cümlesi, yazılı şekle tabi bir sözleşmede tek başına yeterli olmayabilir.

İspat tarafı da benzer: senede bağlı olan bir iddiaya karşı ileri sürülen ve senedin hükmünü ortadan kaldıracak veya azaltacak nitelikteki hukuki işlemler senetle ispat edilir (HMK m.201). Senetle ispat zorunluluğu bulunan hâllerde delil başlangıcı varsa tanık dinlenebilir; delil başlangıcı, iddia konusu işlemi muhtemel gösteren ve karşı taraftan gelmiş bir belgedir (HMK m.202). Müzakere yazışması çoğu zaman tam olarak buradadır: tek başına ispat etmez, ama kapıyı açar.

İki metni satır satır karşılaştırmak elbette gerekir ve bunu yapan araçlar vardır — bu sitedeki sözleşme sürüm farkı aracı da madde bazlı bir karşılaştırma verir. Ama fark ne değiştiğini gösterir; kayıt defteri kimin, neden değiştirdiğini saklar. Biri diğerinin yerine geçmez.

13 Ağustos 2026, 16:02 · KAR · m.7.2 — teslim

Teslim süresinin uzatılması e-posta gövdesinde kabul edildi. Metne işlenmedi; sonraki sürümlerde eski süre kaldı.

E-posta ekinde dolaşan sürümler

E-posta bir taşıyıcıdır, bir depo değil. Aynı ada sahip üç ek, üç ayrı kutuda üç ayrı sürüm demektir ve hiçbirinin diğerinden haberi yoktur. Sonuç her dosyada aynı biçimde görünür: iki kişi aynı anda “en güncel” nüsha üzerinde çalışır, iki ayrı v4 doğar ve birleştirme işi, kimsenin üstlenmediği bir işe dönüşür.

İkinci ve daha sinsi sorun, yukarıdaki kayıtta görülüyor: değişiklik e-postanın gövdesinde kabul edildi, metne hiç işlenmedi. Böyle bir kabul, sözleşmenin kendisinde iz bırakmaz; yalnız bir posta kutusunda yaşar ve o kutuya erişimi olmayan herkes için yoktur.

Hukuken de düz e-posta göründüğü kadar sağlam değildir. Yazılı şekil yerine geçenler TBK m.14/2’de sayılıdır: imzalı bir mektup, asılları borç altına girenlerce imzalanmış telgraf, teyit edilmiş olmak kaydıyla faks veya benzeri iletişim araçları ve güvenli elektronik imza ile gönderilip saklanabilen metinler. Güvenli elektronik imza taşımayan sıradan bir e-posta bu listede yoktur.

Tacirler arasında ise bazı bildirimlerin şekli doğrudan kanunda yazar: diğer tarafı temerrüde düşürmeye, sözleşmeyi feshe veya sözleşmeden dönmeye ilişkin ihbar ve ihtarlar noter aracılığıyla, taahhütlü mektupla, telgrafla ya da güvenli elektronik imza kullanılarak kayıtlı elektronik posta sistemiyle yapılır (TTK m.18). “Fesih e-postası attık” cümlesi, tacirler arası bir uyuşmazlıkta bu maddeye takılır.

Çözüm bir yasak değil, bir iş bölümüdür: metnin yaşadığı tek bir yer olur; e-posta yalnız bildirim taşır. Gönderilen ileti eki değil, esas nüshanın adını ve bulunduğu yeri söyler. Böylece “en güncel hâli kimde” sorusu ortadan kalkar — çünkü sorunun tek bir cevabı olur. Data room kavramı ve standart klasör yapısı tam da bu tek yeri kurmak içindir.

Yazışmanın kendisi de atılmaz. Tacir bakımından alınan ticari mektuplar ve gönderilen ticari mektupların suretleri saklanması zorunlu belgeler arasındadır ve on yıl saklanır (TTK m.82). Uygulamada bu, müzakere yazışmasının dosyanın parçası olduğu anlamına gelir — posta kutusunda değil, dosyada.

10 Ağustos 2026, 10:30 · MUV · dosya adı

Metin, sozlesme_son_final_v2_SON.docx adıyla gönderildi. Karşı taraf iki gün sonra aynı ada bir “(1)” ekleyerek geri gönderdi.

Adlandırma: önce ve sonra

Dosya adı hiçbir hukuki sonuç doğurmaz; hiçbir kanun maddesi dosya adını düzenlemez. Ama ad, dosyaya bakan herkesin ilk okuduğu şeydir ve bir kelime kadar yer kaplayan bilgiyi bedavaya taşır. Aşağıdaki sol sütun, gerçek dosyalarda en sık görülen adlardır — hepsi aynı hatayı yapar: durumu ada, sıraya ise kelimeye yükler.

Şemanın tek kuralı vardır ve teknik değildir: ad, dosyayı açmadan cevaplanabilecek soruları cevaplasın. Hangi sözleşme, kaçıncı sürüm, kimden geldi, ne zaman, işaretli mi temiz mi. Bunların hiçbiri metnin içinde aranmaz; beşi de klasör görünümünde okunur. Ad bunu yapmıyorsa, eksik olan bilgi her seferinde dosya açılarak yeniden üretilir.

Adlandırma, tek başına bir sistem değildir — yalnızca en ucuz olanıdır. İmzadan önce bakılacak maddeler listesi ile birlikte kullanıldığında, her turun sonunda hem metin hem dosya aynı anda kontrol edilmiş olur.