← Dokümantasyon ana sayfa

Timeline

Bu sayfa özet değil; mimari kararların detaylarını ve kararların nedenlerini tarih sırasıyla içerir.

Sıralama:

  1. 2026-02-13 14:53

    Faz 0A kapanış oturumu (detaylı)

    Owner ile canlı analiz seansında legacy ekranlar, iş kuralları ve veritabanı birlikte okunarak Faz 0A kapatıldı.

    • Owner adım adım ekran akışlarını aktardı; agent her ekranı iş akışı, kural, risk ve yeni model etkisiyle ayrıştırdı.
    • Kritik model netleşti: 3 talep tipi (bireysel open, kurumsal kapalı, kurumsal open-birey) tek omurgada ele alınacak.
    • Kurumsal teklif/revizyon -> açılan eğitim -> oturum -> katılımcı zinciri DB/FK ile doğrulandı.
    • Sınıf kapatma/yeniden açma, meeting lifecycle, merge, blacklist, retention ve rapor güvenliği için seçenekli karar setleri owner ile kapatıldı.
    • Rapor güvenliği kuralı sabitlendi: serbest export yok, admin onayı + max row limiti + limit üstü veri için ek onay.
    • Yeni modül fikirleri (hakediş, ön muhasebe, kârlılık vb.) ön onaylandı; detay tasarım modül geliştirme başlangıcına bırakıldı.

    Karar: Faz 0A tamamlandı; Faz 0B'de paydaş odaklı (Design Thinking) UI/UX akış tasarımına geçilecek.

  2. 2026-02-13 14:36

    Faz 0A tamamlandı, Faz 0B eşiğine gelindi

    Legacy ekranlar ve veritabanı detaylı analiz edilerek iş akışı kilitlendi; yeni ek modüller için ön onay alındı.

    • Legacy menü/ekran akışları ve kritik business kuralları çıkarıldı.
    • DB şema + FK + index + lookup + rol/aksiyon verileri analiz edilerek akışlarla eşleştirildi.
    • 3 ana talep tipi modeli doğrulandı (bireysel open, kurumsal kapalı, kurumsal open-birey).
    • Sınıf kapatma/yeniden açma, meeting lifecycle, merge, blacklist, retention gibi kritik konular seçenekli şekilde netleştirildi.
    • Yeni modüller (hakediş, ön muhasebe, kârlılık vb.) ön onaylandı; detaylar geliştirme başlangıcına bırakıldı.

    Karar: Faz 0A kapatıldı; sıradaki adım Faz 0B (UI/UX akış ve bilgi mimarisi) hazırlığı.

  3. 2026-02-13 02:51

    Master Plan revizyonu: Business geliştirme fazı eklendi

    Planın eksik noktası giderildi; business modüllerin ana geliştirme fazı açıkça tanımlandı.

    • Master Plan uçtan uca tekrar kontrol edildi.
    • Business modüllerin geliştirilmesi Faz 2 olarak eklendi ve ana üretim fazı olarak işaretlendi.
    • Faz numaraları yeniden düzenlendi: Event/Worker Faz 3, AI Faz 4, Migration Faz 5, Staging/Güvenlik Faz 6.
    • Her modülde test kapısı (Unit+Integration+Playwright) zorunlu yaklaşımı faz içine işlendi.

    Karar: Geliştirme omurgası artık eksiksiz: analiz/çekirdek sonrası business modül üretimi resmi faz olarak tanımlandı.

  4. 2026-02-13 02:47

    Faz 0C framework seti belirlendi

    Platform çekirdeğinde yeniden yazmak yerine yaygın ve olgun frameworklerle ilerleme kararı alındı.

    • Auth/AuthZ için ASP.NET Core Identity + policy-based authorization önerildi.
    • Veri katmanı EF Core + Npgsql, validasyon için FluentValidation seçeneği işlendi.
    • Logging/observability için Serilog + OpenTelemetry standardı eklendi.
    • Event-first için MediatR; outbox/entegrasyon eventleri için MassTransit/CAP seçenekleri notlandı.
    • Amaç: build yerine compose; hız + sürdürülebilirlik + topluluk standardı.

    Karar: Çekirdek bileşenlerde mümkün olan yerde hazır/popüler frameworkler kullanılacak.

  5. 2026-02-13 02:42

    Faz 0 genişletildi: analiz + UX + platform çekirdeği

    Modül geliştirmeden önce legacy analiz, UI/UX akışı ve platform standartlarının zorunlu olduğu model kabul edildi.

    • Faz 0 üçe ayrıldı: 0A (Legacy/iş mantığı), 0B (UI/UX akışı), 0C (platform çekirdeği).
    • Role yönetimi, auth/authorization, logging/audit ve exception yönetimi modül öncesi zorunlu kılındı.
    • Geliştirme disiplini: çekirdek standartlar tamamlanmadan modül koduna geçilmeyecek.

    Karar: Faz 1 modül geliştirmesi öncesi Faz 0A/0B/0C tamamlanacak.

  6. 2026-02-13 02:24

    Release güvenlik fazı eklendi

    Canlıya çıkış öncesi staging ve penetrasyon testlerini zorunlu kılan yeni faz master plana işlendi.

    • Master Plan'a Faz 5 (Staging ve Güvenlik Geçidi) eklendi.
    • Staging ortamı doğrulanmadan production deploy yapılmayacak.
    • Prod öncesi penetrasyon testleri ve security scan zorunlu hale getirildi.
    • Bulgu varsa düzeltme + yeniden test döngüsü uygulanacak.

    Karar: Staging + güvenlik geçidi, release sürecinin zorunlu adımı olarak sabitlendi.

  7. 2026-02-13 02:17

    Test politikası kilitlendi

    UI test stratejisi resmi karar haline getirildi: maksimum otomasyon, minimum manuel kontrol.

    • UI akışlarında Playwright coverage hedefi %100 (kritik kullanıcı akışları bazında) olarak sabitlendi.
    • No test, no merge kuralı benimsendi: test geçmeden merge/deploy yok.
    • PR kapısında Unit + Integration + Playwright smoke testleri zorunlu olacak.
    • Nightly tam regresyon (full Playwright) çalıştırma politikası tanımlandı.

    Karar: Test kapısı zorunlu: otomasyon geçmeden release yok.

  8. 2026-02-13 01:04

    Altyapı doğrulama tamamlandı ve MVC iskelete geçildi

    Render + Supabase bağlantısı canlı doğrulandı, geçici Node bootstrap kaldırılarak ASP.NET Core MVC iskeleti yayına alındı.

    • Render üzerinde /health endpoint doğrulandı.
    • Supabase env değişkenleri eklendi ve /db-check bağlantı testi başarıyla geçti.
    • Geçici bootstrap servisinden çıkılıp ASP.NET Core MVC skeleton kuruldu.
    • Docker tabanlı deploy akışı .NET 8 için güncellendi.
    • Faz 0 öncesi altyapı adımı tamamlandı; sıradaki adım legacy keşif/modelleme.

    Karar: Faz 0 öncesi teknik temel hazır: Render + Supabase + ASP.NET Core MVC skeleton aktif.

  9. 2026-02-12 23:46

    DB kararı revize edildi (Render Postgres → Supabase)

    Render free Postgres'in 30 günlük sınırı nedeniyle DB tercihi Supabase'e alındı.

    • Platform kararı Render olarak korundu; yalnızca DB katmanı revize edildi.
    • Render Postgres free katmanda 30 günlük limit olduğu görüldü.
    • Uzun vadeli ücretsiz kullanım esnekliği ve cömert free plan nedeniyle Supabase tercih edildi.
    • Yeni stack: Render (deploy) + Supabase Postgres (DB).

    Karar: Eğitim CRM deployment stack: Render + Supabase Postgres.

  10. 2026-02-12 23:30

    Deployment kararı revize edildi (Railway → Render)

    Platform ve DB kararı güncellendi: Render + Render Postgres ile devam.

    • Railway platformu tamamen iptal edildi.
    • Yeni deployment hedefi Render olarak belirlendi.
    • DB katmanı için şimdilik Render Postgres tercih edildi.
    • GitHub tabanlı deploy akışı Render üzerinde yeniden kurgulanacak.
    • Gerekirse ileride platform/DB revizyonu için migration opsiyonu açık bırakıldı.

    Karar: Eğitim CRM deployment stack: Render + Render Postgres.

  11. 2026-02-12 19:30

    Mimari kilit v2 (detay)

    Uygulamaya başlanabilecek teknik ve mimari çerçeve netleşti.

    • Backend: ASP.NET Core (MVC) + Docker
    • Frontend: Razor (tek uygulama, tek deploy)
    • Data: Supabase Postgres (güncel karar)
    • Worker: Hangfire + Postgres storage
    • İlk host: Render (Railway iptal)
    • Mimari stil: Clean Architecture prensiplerine uyumlu katmanlı yaklaşım (domain odaklı ayrım, bağımlılıkların içe doğru akması, altyapının değiştirilebilir tutulması).
    • Amaç: uzun vadede bakım kolaylığı, test edilebilirlik ve modül bazlı genişleme.

    Karar: Architecture Lock v2 ile teknik yön ve uygulama omurgası kilitlendi.

  12. 2026-02-12 15:21

    AI provider bağımsızlığı sabitlendi

    Lock-in riskini azaltan uzun vadeli AI katman prensibi alındı.

    • AI entegrasyonu provider-independent (adapter/port) olacak.
    • Cloud API ile başlansa bile self-hosted/open-source geçiş açık kalacak.
    • Routing/fallback yaklaşımıyla sağlayıcı değişimi çekirdek akışı bozmadan yapılabilecek.

    Karar: AI katmanı stratejik olarak provider-independent tasarlanacak.

  13. 2026-02-12 14:05

    Kapsam, AI ve maliyet çerçevesi

    Kapsam şişmesini engelleyen net sınırlar çizildi.

    • STT (ses transkript) varsayılan kapsam dışında bırakıldı.
    • STT tamamen reddedilmedi; opsiyonel ve admin-only olarak konumlandı.
    • AI maliyeti modül/feature bazında planlanacak model benimsendi.
    • Erken bütçe hedef bandı 50–100 USD/ay olarak notlandı.

    Karar: Önce iş akışı, sonra AI çağrı noktaları ve maliyet optimizasyonu.

  14. 2026-02-12 12:01

    Belgesel hedefi netleşiyor

    Süreç teknik nottan paylaşılabilir belgesel modeline geçti.

    • Soru → Öneri → Karar → Aksiyon → Sonuç akışı standardize edildi.
    • Timeline ve karar günlüğü dosya yapısı netleştirildi.
    • Sadece son karar değil, kararın evrimi de kayda alınmaya başlandı.

    Karar: Tarih bazlı belgesel yaklaşımı kalıcı standart oldu.

  15. 2026-02-12 11:49

    Kıvılcım: Eğitim CRM fikri doğuyor

    Legacy bilgiyi koruyup modern yapıya geçiş hedefi netleşti.

    • Yeni CRM geliştirme ihtiyacı, eski sistemde biriken operasyonel yük nedeniyle doğdu.
    • Acele kod yerine keşif, kayıt ve karar süreci başlatıldı.
    • Greenfield code + brownfield knowledge yaklaşımı benimsendi.
    • Kodlama başlamadan önce migration güvenliği ve geçmiş iş aklını koruma ilkesi sabitlendi.

    Karar: Sıfırdan geliştirme, legacy akış bilgisi korunarak ilerleyecek.