Güvenli, küçük yinelemeler için 'değiştirmeyin' istem kalıbı

Küçük değişikliklerin neden sık sık başka yerleri bozduğunu\n\n“Küçük” bir değişiklik nadiren küçük kalır. Bir düğme etiketini düzeltmesini istersiniz ve birden sayfa düzeni kayar, bir form doğrulamayı durdurur veya bir ödeme adımı farklı davranır. Uygulamalar bağlı sistemlerdir. UI, mantık, veri ve entegrasyonlar birbirine dayanır.\n\nSık karşılaşılan nedenlerinden biri belirsiz sınırlar. Bir istek “kaydoluşu daha basit yap” derse, uygulayıcı (insan veya AI) “daha basit”in ne demek olduğunu tahmin etmek zorunda kalır. Tahmin, alanları kaldırma, adımları değiştirme, kopyayı ayarlama veya doğrulamayı yeniden yazma gibi ek düzenlemelere yol açar. Bir diğer neden de gizli bağımlılıklardır. Küçük bir UI değişikliği, beş başka ekranda kullanılan bir bileşeni yeniden kullanabilir.\n\nGüvenli bir yineleme, istenen tek iyileştirmeyi almanızı sağlar ve her şeyin geri kalanı etkili şekilde aynı kalır. Teknik olmayan bir ekip için bu, iş akışının kullanıcılara aynı hissetmesi, destek senaryolarının ürünle eşleşmesi ve raporlamanın anlamlı kalması demektir. Teknik bir ekip için bu, rotalarda, veri şekillerinde, API sözleşmelerinde veya kenar durum davranışlarında beklenmedik değişiklik olmaması anlamına gelir.\n\nBunu mümkün kılmak için, hareket etmeyecek olanları dondurmanız gerekir. Pratikte bu genellikle kritik akışları (kullanıcının geçtiği tam adımlar), UI ve UX ayrıntılarını (düzen, boşluk, etkileşim davranışı), iş kurallarını (fiyatlandırma, izinler, doğrulama), veri davranışını (ne saklanır ve ne zaman) ve entegrasyonları (analitik olayları, e-postalar, ödemeler, dış API'ler) içerir.\n\nBu “değiştirme” istem kalıbı, tahminleri ortadan kaldırıp değişiklik kapsamını daraltarak riski azaltır. Bu bir garanti değildir. Orijinal davranış kötü tanımlanmışsa, değişiklik paylaşılan bileşenleri etkiliyorsa veya sonucu doğrulamazsanız sapma olabilir. Hedef, daha az sürpriz ve daha hızlı onaydır.\n\n## “Değiştirme” istem kalıbı nedir\n\nDeğiştirme istem kalıbı, bir spesifik güncelleme isterken her şeyi net şekilde kilitlemenin basit bir yoludur. İstediğiniz tek değişikliği isimlendirirsiniz, sonra güncellemeden sonra aynı kalması gereken kısımların kısa bir dondurma listesini yazarsınız.\n\nBu önemlidir çünkü modeller genellikle yardımcı olmaya çalışırken dosyaları yeniden düzenleyebilir, yeniden adlandırabilir, yeniden organize edebilir veya mantığı “temizleyebilir”. Çıktı yine çalışsa bile bu ekstra değişiklikler hatalara, davranış değişikliklerine veya incelemeyi zorlaştırmaya yol açabilir.\n\nBu iki isteği karşılaştırın:\n\n“Ayarlar sayfasını geliştirin.” Bu tasarım değişikliklerine, yeni kopyaya, düzen kaymalarına ve mantık ayarlarına davetiye çıkarır.\n\n“Sadece 'Telefon' etiketini 'Cep telefonu' olarak değiştirin. Düzeni, doğrulamayı veya kaydetme davranışını değiştirmeyin.” Bu dar, test edilebilir ve daha güvenlidir.\n\nİyi bir dondurma listesi genellikle üç alanı kapsar:\n\n- Akışlar (kullanıcı yolculukları): kullanıcıların izlediği adımlar ve hangi ekranların göründüğü.\n- UI ve UX ayrıntıları: düzen, boşluk, alan sırası, düğme konumları ve etkileşimler.\n- İş kuralları ve veri davranışı: doğrulama kuralları, fiyat hesaplaması, izinler, veritabanı yazımları ve API yanıtları.\n\nBu kalıbı sohbet tabanlı bir yapı aracında (Koder.ai gibi) kullandığınızda, yinelemeler genellikle daha hızlı ilerler çünkü model tek düzenlemeye odaklanır ve istemeden geniş “iyileştirmeler” yapmaz.\n\n## Yeniden kullanılabilir temel şablon\n\nBu kalıp en iyi tek bir küçük kontrat gibi okunduğunda çalışır: bir net hedef, aynı kalması gerekenlerin dondurulduğu liste ve sonucu doğrulamak için birkaç kontrol.\n\nAşağıdaki şablonu kopyalayıp köşeli parantezleri doldurun. Kısa ama spesifik tutun.\n\n```text

Goal (one sentence):

• Change: [describe the one small change you want]

Context (1-3 sentences):

• Current behavior: [what happens today]
• Desired behavior: [what should happen after]

DO NOT CHANGE (must remain identical):

• Critical flows: [e.g., sign up -> checkout -> receipt stays the same]
• UI/UX that must not move: [e.g., button location, labels, navigation order]
• Business rules: [e.g., pricing, permissions, validation rules]
• Data behavior: [e.g., database schema, stored fields, migration rules]

Constraints (limit drift):

• Scope: [only this screen / only this endpoint / only this component]
• Files/modules (if known): [list a couple, or say “only touch what’s necessary”]
• No refactors: do not rename, reorganize folders, or change formatting beyond the touched lines

Acceptance checks (how I will verify):

1. [a simple before/after check]
2. [a user path that must still work]
3. [a rule that must still hold]

Output requested:

• Provide a brief diff-style summary: what changed, where, and why
• Call out any risk or unclear requirement before implementing