Merhaba claude ile yaptığım yazılımın temasını değiştirdikten sonra bi kaç düzeltme yapmak istedim lakin yeni tasarımla yapıyor.
Eski yazılımı yükleyip yeni düzenlemeleri ve özellikleri yaptırırsam kodları bozarmı?
Detaylı bilgi arıyorum.
Claude mevcut yazılım düzenleme
4
●204
- 06-09-2026, 17:06:54
- 06-09-2026, 17:09:09Kullanın bunu hocam iyi forumlar.
Mevcut yazılımım üzerinde geliştirme ve düzeltme yapmanı istiyorum.
ÖNEMLİ: Bu projede daha önce tema/tasarım değişikliği yapılmıştı. Ancak bundan sonraki geliştirmelerde YENİ TEMA KESİNLİKLE REFERANS ALINMAYACAKTIR.
Ben sana projenin ESKİ VE STABİL çalışan sürümünü yükleyeceğim. Bundan sonraki tüm geliştirmeleri bu sürüm üzerinden yapacaksın.
ANA KURAL:
Eski yazılımın mevcut mimarisini, dosya yapısını, çalışma mantığını, mevcut UI yapısını, CSS yapılarını, componentlerini, API bağlantılarını, veritabanı işlemlerini, fonksiyonlarını ve mevcut tasarımını koru.
Ben özellikle istemediğim sürece:- Tema değiştirme.
- UI tasarımını yenileme.
- Renkleri değiştirme.
- Fontları değiştirme.
- Componentleri yeniden tasarlama.
- Sayfa düzenlerini değiştirme.
- Responsive yapıyı değiştirme.
- Mevcut CSS yapısını değiştirme.
- Mevcut componentleri başka componentlerle değiştirme.
- Framework veya kütüphane değiştirme.
- Projenin mimarisini değiştirme.
- Dosyaları gereksiz yere taşıma.
- Çalışan kodları refactor etme.
- Çalışan özellikleri yeniden yazma.
- Gereksiz optimizasyon yapma.
- Yeni tasarımda bulunan hiçbir özelliği otomatik olarak eski projeye taşıma.
Örneğin ben:
"X özelliğini ekle"
dersem sadece X özelliğini mevcut yazılım mimarisine ve mevcut tasarım diline uygun şekilde ekle.
"Y hatasını düzelt"
dersem sadece Y hatasını düzelt. Bunun dışında çalışan kodlara dokunma.
ÖNEMLİ: Yeni yüklediğim eski/stabil sürüm, projenin TEK DOĞRU KAYNAĞI olarak kabul edilecek.
Daha önce yaptığımız tema değişikliklerini, yeni tasarımı veya önceki konuşmalardaki tasarım kararlarını referans alma.
Önce yüklediğim projenin mevcut yapısını analiz et.
Kod yazmaya başlamadan önce:- Projenin klasör/dosya yapısını incele.
- Ana giriş noktalarını tespit et.
- Mevcut UI yapısını incele.
- API ve backend bağlantılarını incele.
- Veritabanı işlemlerini incele.
- Mevcut component/fonksiyon yapısını incele.
- Özelliğin hangi dosyaları etkilediğini belirle.
- Gereksiz dosyalara dokunma.
KODU BOZMAMA PRENSİBİ:
Bir değişiklik yaparken mevcut çalışan özellikleri korumak birincil önceliktir.
Yeni özellik eklerken mevcut özelliklerin çalışma şeklini değiştirme.
Bir dosyada değişiklik yapmak gerekiyorsa, o dosyada yalnızca gerekli bölümleri değiştir.
Gereksiz yere tüm dosyayı baştan yazma.
Mevcut fonksiyonlar çalışıyorsa onları yeniden oluşturma.
Mevcut API endpointlerini değiştirme.
Mevcut database tablolarını, kolonlarını veya sorgularını değiştirme; bunu özellikle istemediğim sürece yapma.
Mevcut authentication/login sistemine dokunma.
Mevcut kullanıcı yetkilendirme sistemine dokunma.
Mevcut URL/routing yapısını değiştirme.
Mevcut responsive davranışı bozma.
GERİYE DÖNÜK UYUMLULUK:
Yeni özellikler mevcut sistemle geriye dönük uyumlu olmalıdır.
Mevcut kullanıcıların ve mevcut verilerin çalışmasını engelleyecek değişiklikler yapma.
Database değişikliği zorunluysa önce bana bildir ve hangi tabloda/kolonda ne değişeceğini açıkla.
BREAKING CHANGE oluşturabilecek herhangi bir değişiklik yapmadan önce beni uyar.
TASARIM KURALI:
Eski/stabil sürümde bulunan tasarım bundan sonra korunacaktır.
Yeni tema, yeni renk paleti veya yeni UI yaklaşımı kesinlikle uygulanmayacaktır.
Yeni bir özellik eklenmesi gerekiyorsa bu özellik mevcut tasarım sistemine uyarlanacaktır.
Örneğin mevcut buton yapısı varsa yeni özellik için yeni bir buton tasarlama; mevcut buton stilini kullan.
Mevcut kart yapısı varsa yeni içerikleri mevcut kart yapısına adapte et.
Mevcut modal yapısı varsa yeni modalı mevcut modal yapısına adapte et.
Kısacası:
YENİ ÖZELLİK → ESKİ TASARIMA UYARLANACAK.
ESKİ TASARIM → YENİ ÖZELLİĞE UYARLANMAYACAK.
DEĞİŞİKLİK ÖNCESİ KONTROL:
Herhangi bir kod değişikliği yapmadan önce bana kısaca:- Hangi dosyaların değişeceğini
- Hangi fonksiyon/componentlerin etkileneceğini
- Değişikliğin mevcut sisteme etkisini
- Herhangi bir risk olup olmadığını
Eğer istediğim değişiklik mevcut kod yapısıyla uyumlu şekilde yapılabiliyorsa mevcut yapıyı koruyarak uygula.
Eğer mevcut mimaride değişiklik yapmak zorunluysa bunu otomatik olarak yapma. Önce neden gerekli olduğunu açıkla.
KOD DEĞİŞİKLİĞİ SONRASI:
Değişiklikten sonra kontrol et:- Mevcut özellikler çalışıyor mu?
- Yeni özellik çalışıyor mu?
- Console/runtime hatası oluşuyor mu?
- API bağlantıları bozuldu mu?
- Database işlemleri bozuldu mu?
- Responsive yapı bozuldu mu?
- Eski UI/tasarım korunuyor mu?
- Gereksiz dosya veya kod değişikliği yapıldı mı?
Bu projede senden istediğim şey mevcut yazılımı yeniden tasarlamak değil, mevcut çalışan yazılımı KORUYARAK geliştirmektir.
Eski/stabil proje = SOURCE OF TRUTH.
Yeni tema = REFERANS DEĞİL.
Benim yeni mesajımda açıkça istemediğim hiçbir tasarım değişikliği yapılmayacak.
Ben özellik veya düzeltme istediğimde:
MEVCUT KODU ANALİZ ET → GEREKLİ DOSYAYI BUL → MİNİMUM DEĞİŞİKLİK YAP → MEVCUT SİSTEMİ KORU → TEST ET.
Bu kuralları proje boyunca koru ve sonraki mesajlarımda da bunlara göre hareket et. - 06-09-2026, 17:31:35yukarıda arkadaşın biri öneride bulunmuş, ancak o da bağlama sıkıştırılan ve performansı olumsuz etkileyip uzun vade de halisünasyona neden olacak basit bir mantık. yz'ye bir iş yaptırmadan önce, mühendislik düzeyinde yapacağınız işin kurallarını belirlemeniz gerekir.
AGENTS.md ARCHITECTURE.md CHANGELOG DEVELOPER_ASSET_CUSTODY.md DEVELOPER_SECURITY_OPERATIONS.md PRE_RELEASE_AUDIT.md ROADMAP.md
ki bu dosyaları oluşturmak da yetmez, her şeyi netleştirmelisiniz bir projeye başlamadan önce. şu 7 dosyada binlerce satır anlamsal veri var, ancak tek bir başlangıç noktası var ve buradaki katı kuralları uygulamaya zorunlu, bu zorunluluk kapsamında model sadece mevcut iş süreci ile alakalı satırları okuyor, geriye kalan binlerce satır es geçiliyor. misal son günlerde herkesin yz'nin aynı tasarımlar üretmesinden şikayetçi, niye? çünkü ya bootstrap ya tailwind kullanıyorda ondan. ben hiç yz olmadan oturup sıfırdan css yazdım, dom içerisinde kullanacağı sınıflar için bile kural atadım. ai ile yapılan işlerdeki dom'a baktığınızda tek bir elementte onlarca css classı bulunuyor, ki bu bile yetmiyor bazen o elemente override yapmak için inline müdahale de bulunuyor. benim dökümanım render edildikten sonra tertemiz çıkıyor. çünkü bilinçli hareket ediyorum ve yz'ninde bilinçli hareket etmesini sağlıyorum. siz tüm bilinci yz kontrolüne bırakırsanız, hem çok token harcarsınız hemde uzun vade de işlerin spagettileştiğini görürsünüz. şu kısacacık sürede verdiğim bilgileri edinmeniz için bile günlerce araştırma yapmanız gerekebilirdi. mutlaka önerdiğim bu yapıyı uygulayın ama kontrolü yz'ye bırakmayın. misal architecture.md ne yapar ve işlevi nedir nasıl doldurmalıyız proje kapsamında diye sorduğunda, verdiği yanıtı okumalı, anlamalı ve sorgulamalısın. sorgulama "ama" diyebilmek için önemli; ama bizim buna neden ihtiyacımız var, ama biz şunu yapacağız aslında, ama böyle yaparsak burası ne olur. kısaca "ama" önemlidir.
