kortext 3.0.0 → 3.1.0

package/workflows/02b-spike-workflow.md

@@ -1,120 +0,0 @@
-# Spike Workflow (`!start spike`)
-
-Bu akış, bir geliştirme görevine başlamadan önce "acaba bu teknik çözüm işe yarar mı?" sorusunu yanıtlamak için kullanılır. Time-boxed bir araştırma/deneme sürecidir. Sprint kapsamını değiştirmez; çıktısı ya bir `decisions.md` ADR kaydı ya da yeni bir backlog Task item'ıdır.
-
-## Girdi ve Çıkış
-
-- **Başlangıç koşulu:** Bir görevi planlamadan veya başlatmadan önce teknik belirsizlik varsa ve bunu çözmek için araştırma/deneme gerekiyorsa.
-- **Girdi:** +prime veya +engineering-manager'dan gelen spike konusu ve time-box süresi.
-- **Çıktı:** `workspace/memory/decisions.md` içinde ADR kaydı **veya** yeni backlog Task item (kapsam netleştiyse).
-- **Sonraki akış:** ADR onaylandıktan sonra `04-development-cycle.md`; kapsam belirsizleştiyse `02-planning-pipeline.md`.
-
-> [!NOTE]
-> Spike bir özellik değildir. Kod yazılabilir ama o kod production'a gitmez. Öğrenim hedeftir, çıktı değil.
-
-## Time-Box Kuralı
-
-Spike başlamadan önce süre netleştirilir. Süre aşıldığında devam edilmez; mevcut öğrenimle karar alınır.
-
-| Spike Türü | Önerilen Süre | Uzatma |
-|---|---|---|
-| Kısa araştırma (API inceleme, dokümantasyon okuma) | 2 saat | Yok |
-| Teknik PoC (küçük deneme kodu) | 4-8 saat | +prime onayıyla bir kez |
-| Kapsamlı mimari araştırma | 1 gün | +prime onayıyla |
-
-## Akış
-
-### 1. Spike Tanımı
-
-**Sorumlu:** +engineering-manager (teknik spikeler), +product-manager (ürün spikeler)
-
-1. Spike konusunu ve sorusunu netleştir:
-   - **Hipotez:** "X yöntemi ile Y sorunu çözülebilir."
-   - **Başarı kriteri:** "Bunu doğrulamak için ne görmeliyim?"
-   - **Time-box:** Kaç saat/gün?
-2. `workspace/memory/context/[agent-name]-active.md` dosyasını oluştur.
-3. +prime'a bildir:
-
-> [!NOTE] SPİKE BAŞLIYOR
-> +prime,
-> **Konu:** [spike sorusu]
-> **Hipotez:** [X yöntemiyle Y çözülebilir]
-> **Time-box:** [süre]
-> Başlıyorum.
-
----
-
-### 2. Araştırma / Deneme
-
-**Sorumlu:** İlgili ajan (+engineering-manager, +backend-developer, vb.)
-
-1. Hipotezi test et:
-   - Dokümantasyon ve kaynak tara.
-   - Gerekirse küçük bir PoC (Proof of Concept) yaz — `workspace/archive/spike-[konu]/` dizinine kaydet.
-2. Bulguları not al:
-   - Hipotez doğrulandı mı?
-   - Beklenmedik kısıtlamalar var mı?
-   - Hangi alternatif yollar keşfedildi?
-3. Time-box dolmadan sonuca ulaşılırsa ilerle; doluyorsa mevcut bilgiyle karar al.
-
-> [!WARNING]
-> Time-box dolduğunda "biraz daha araştırayım" deme. Durumu +prime'a bildir ve mevcut öğrenimle karar al.
-
----
-
-### 3. Karar ve Çıktı
-
-**Sorumlu:** +engineering-manager
-
-Spike tamamlandığında iki seçenek:
-
-| Durum | Aksiyon |
-|---|---|
-| Hipotez doğrulandı, yol netleşti | `workspace/memory/decisions.md`'ye ADR yaz → `04-development-cycle.md` |
-| Kapsam belirsizleşti veya yeni Task gerekli | `kortext-backlog-add.py` ile Task aç → `02-planning-pipeline.md` |
-| Hipotez reddedildi, alternatif yol gerekli | +prime'a sun, karar bekle |
-
----
-
-### 4. ADR Formatı (Spike Çıktısı)
-
-`workspace/memory/decisions.md` içine şu formatta eklenir:
-
-```md
-## [YYYY-MM-DD] — Spike: [konu-başlığı]
-
-**Soru:** [Araştırılan teknik soru]
-**Hipotez:** [Test edilen hipotez]
-**Time-box:** [harcanan süre]
-
-### Bulgular
-[Ne öğrenildi? Kısa maddeler halinde]
-
-### Karar
-[Hipotez doğrulandı / reddedildi / kısmen doğrulandı]
-**Seçilen yol:** [hangi yaklaşım benimseniyor]
-**Red edilen yol:** [hangi alternatif neden reddedildi]
-
-### Sonraki Adım
-[Backlog Task ID veya "ADR geçerli, geliştirme başlayabilir"]
-```
-
----
-
-## Bildirim
-
-> [!NOTE] SPİKE TAMAMLANDI
-> +prime,
-> **Konu:** [spike sorusu]
-> **Süre:** [harcanan süre / time-box]
-> **Sonuç:** [Doğrulandı / Reddedildi / Kısmen]
-> **Karar:** [decisions.md kaydı veya yeni Task ID]
-> Devam için onayını bekliyorum.
-
-> [!NOTE] SPİKE TIME-BOX DOLDU
-> +prime,
-> **Konu:** [spike sorusu]
-> **Durum:** Time-box doldu. Sonuca ulaşılamadı.
-> **Mevcut bulgular:** [kısa özet]
-> **Seçenekler:** [a) daha fazla araştırma — ek süre / b) mevcut bilgiyle karar al / c) iptal]
-> Komutunu bekliyorum.

package/workflows/03-environment-setup.md

@@ -1,99 +0,0 @@
-# Environment Setup (`!setup environment`)
-
-Bu akış, onaylı analiz çıktıları hazırlandıktan sonra projenin çalışabilir ortamını kurar.
-
-## Girdi ve Çıkış
-
-- **Başlangıç koşulu:** `../workspace/references/tech-stack.md`, `../workspace/references/security-rules.md`, `../workspace/references/db-schema.md` ve gerekli ürün/teknik kararları onaylanmış olmalıdır.
-- **Girdi:** Onaylı referans dosyaları ve +prime tarafından sağlanan gerçek secret değerleri.
-- **Çıkış:** Çalışan geliştirme ortamı, belgelenmiş erişim yapısı, secrets scanning kurulumu ve smoke test sonucu.
-- **Sonraki akış:** Ortam doğrulandıktan sonra `04-development-cycle.md`.
-
-## Servis Envanteri ve Credential Setup
-
-1. **+devops-engineer:** `../workspace/references/tech-stack.md`, `../workspace/references/security-rules.md` ve `../workspace/references/db-schema.md` dosyalarını inceleyerek tüm harici servisleri tespit eder.
-2. Her servisi iki kategoriye ayırır:
-	- **Yapılandırma bilgisi:** URL, proje adı, public key, platform adı, ortam adı gibi açık bilgiler. `../workspace/references/access.md` içinde tutulur ve versiyon kontrolüne dahil edilebilir.
-	- **Gizli anahtar:** API key, secret, token, connection string gibi gerçek değerler. `.env.example` içinde yalnızca anahtar adı ve açıklaması yer alır; gerçek değerler sadece `.env` dosyasında tutulur.
-3. Servis envanterinden elde edilen açık yapılandırma bilgilerini `../workspace/references/access.md` dosyasına yazar.
-4. Gerekli environment variable anahtarlarını ve sade açıklamalarını `.env.example` dosyasına yazar.
-5. `../workspace/references/access.md` ve `.env.example` dosyalarını +prime'a sunar.
-
-> [!NOTE]
-> Talep metnini teknik jargon kullanmadan, sade bir dille hazırlar.
-> Her değişken için +prime'ın teknik bilgi sahibi olmadığı dikkate alınarak **sade bir açıklama** yazılır. Açıklamada şu bilgiler yer alır: değişkenin **ne olduğu**, **nereden temin edileceği** ve **neden gerektiği**. 
-> Gerçek değerler **asla** yazılmaz.
-
-### Ara Bildirim
-
-> [!NOTE] ORTAM KURULUYOR
-> +prime, 
-> `../workspace/references/access.md` ve `.env.example` hazır.
-> Lütfen `access.md` içindeki boş yapılandırma alanlarını ve proje root dizinindeki `.env` dosyasını doldur.
-> Doldurduktan sonra `!approve access` ve `!approve .env` komutlarını bekliyorum.
-
-**+prime:**
-1. `../workspace/references/access.md` dosyasındaki boş alanları doldurur.
-2. `.env.example` dosyasındaki açıklamaları takip ederek gerçek anahtarları temin eder.
-3. Proje root dizininde `.env` dosyasını oluşturarak gerçek değerleri yazar.
-
-> [!WARNING] `.env` dosyası **asla** versiyon kontrolüne dahil edilmez. `.gitignore`'da yer almalıdır. +prime dışında hiçbir ajan gizli anahtarlara doğrudan erişemez.
-
-1. **+devops-engineer:** `.env` dosyasındaki anahtar adlarının `.env.example` ile eşleştiğini kontrol eder. Gerçek secret değerlerini okumaz, yazmaz veya raporlamaz.
-2. `../workspace/references/access.md` bilgilerinin doğruluğunu ve erişilebilirliğini doğrular.
-3. Uygulamanın bu yapılandırmayla başarıyla ayağa kalktığını test eder.
-4. Sorun tespit edilirse +prime'a sade bir dille geri bildirim verir ve düzeltme talep eder.
-
-### Secrets Scanning Kurulumu
-
-**+devops-engineer**, proje kurulumunun bir parçası olarak aşağıdaki iki katmandan en az birini yapılandırır:
-
-#### Katman 1 — Pre-commit Hook (Yerel Koruma)
-
-1. Commit anında secrets taraması yapar. Gizli anahtar içeren dosya commit edilmeye çalışılırsa işlem engellenir.
-2. Kullanılan araç proje tech stack'ine göre seçilir. Örn: `detect-secrets`, `gitleaks`, platform-native secret scanning.
-3. Baseline veya konfigürasyon dosyası versiyon kontrolüne dahil edilebilir; `.env` ve gerçek secret dosyaları dahil edilemez.
-
-#### Katman 2 — CI Pipeline Taraması (Merkezi Koruma)
-
-1. Her PR ve push'ta otomatik secrets taraması çalıştırır. Yerel hook'u atlamış commit'leri yakalar.
-2. CI taraması zorunlu status check ise branch protection kurallarına dahil edilir.
-3. Kurulan secrets scanning katmanı `../workspace/references/security-rules.md` ve `../workspace/reports/delivery-reports.md` içinde belgelenir.
-
-### Çıktılar
-
-| Dosya | Sorumlu | VCS | Açıklama |
-|-------|---------|-----|----------|
-| `../workspace/references/access.md` | +devops-engineer | Evet | Servis yapılandırma ve erişim referansı |
-| `.env.example` | +devops-engineer | Evet | Ortam değişkenlerinin anahtar listesi ve açıklamaları |
-| `.env` | +prime | Hayır | Gerçek gizli anahtarlar |
-| `.secrets.baseline` | +devops-engineer | Evet | Secrets scanning baseline dosyası |
-| `.pre-commit-config.yaml` | +devops-engineer | Evet | Pre-commit hook tanımı |
-| `.github/workflows/secrets-scan.yml` | +devops-engineer | Evet | CI secrets tarama pipeline'ı |
-
-## Proje İskeleti
-
-1. **+frontend-developer:** `../workspace/references/file-system.md` yapısına göre frontend proje iskeletini oluşturur veya mevcut iskeleti düzenler.
-2. **+devops-engineer:** `../rules/branching.md` uyarınca repoyu başlatır, `.gitignore` dosyasını hazırlar ve main branch'e doğrudan push'u engelleyecek branch protection kurallarını uygular.
-3. Staging/Production ortamlarını `../workspace/references/access.md` içindeki bilgilere göre ayarlar.
-4. `../workflows/06-deployment-cycle.md` uyarınca CI/CD pipeline'larını aktif eder.
-5. **+db-admin:** `../workspace/references/db-schema.md` uyarınca veritabanlarını oluşturur veya mevcut veritabanı bağlantılarını doğrular.
-
-## Uygulama Kurulumu
-
-1. **+backend-developer:** `../workspace/references/tech-stack.md` ve `../workspace/references/api-reference.md` uyarınca backend bağımlılıklarını yükler, gerekli başlangıç konfigürasyonlarını yapar ve gerekiyorsa mock data setlerini oluşturur.
-2. **+frontend-developer:** `../workspace/references/design-system.md` değerlerini ve `../workspace/references/file-system.md` yapısını projeye uygular.
-
-## Kalite Kontrol (Smoke Test)
-
-1. **+engineering-manager:** Kurulum commit'lerini ve proje iskeletinin `../workspace/references/file-system.md` ile uyumunu denetler.
-2. **+qa-engineer:** Kurulumun hatasız olduğunu doğrulamak için smoke test yapar. Minimum kontroller: build, run, DB connection, API health ve temel UI açılışı.
-3. Sonuçları `../workspace/reports/test-reports.md` dosyasına yazar.
-
-## Bildirim
-
-> [!NOTE] ORTAMLAR KURULDU
-> +prime, 
-> [project-name] tüm ortam eksiksiz kuruldu ve tüm kurulum testlerinden geçti.
-> Sonuçlar `../workspace/reports/test-reports.md` dosyasına yazıldı.
-> Rapor için `!approve/reject test-reports`, ardından geliştirmeye başlamak için `!start development` komutunu bekliyorum.

package/workflows/04-development-cycle.md

@@ -1,203 +0,0 @@
-# Development Cycle (`!start development`)
-
-Bu akış, seçilen backlog item'ının uygulanmasını ve `Review` aşamasına kadar ilerlemesini yönetir.
-
-## Girdi ve Çıkış
-
-- **Başlangıç koşulu:** Düz backlog içinde assignee'si belirlenmiş ve bağımlılıkları çözümlenmiş bir item bulunmalıdır.
-- **Girdi:** İlgili backlog item dosyası, onaylı referanslar ve mevcut handover/context kayıtları.
-- **Çıkış:** Uygulanmış değişiklik, `Test`/`Review` geçiş kayıtları ve güncel handover.
-- **Sonraki akış:** Test için `05-test-cycle.md`; onay sonrası deployment ihtiyacına göre `06-deployment-cycle.md`.
-
-## Otomasyon Çağrıları
-
-> [!TIP] Bu tablo workflow adımlarının hangi script/hook'a bağlandığını gösterir. Tek-kaynak referans: `../settings/INTEGRATION-MAP.md`.
-
-| Adım | Tetikleyici Persona | Script / Hook | Beklenen Çıktı |
-|---|---|---|---|
-| Pick & Plan | Assignee ajan | `scripts/kortext-item-start.py <item> --agent <persona> --summary "..."` | Item `In Progress`, `workspace/memory/context/<agent>-active.md`, otomatik git commit |
-| Implementation (PR açma) | Assignee ajan | `scripts/kortext-item-transition.py <item> --to Test` | Status `Test`, otomatik git commit |
-| PR commit | (otomatik) | `hooks/git-pre-commit.sh` zinciri (secret-scanner → lint → size → backlog-sync → handover → snapshot) | Commit accept/reject |
-| Verification (fail) | Gate sahibi ajan | `scripts/kortext-item-transition.py <item> --to "In Progress"` | Status `In Progress`, otomatik git commit |
-| Verification (pass) | Son gate ajanı | `scripts/kortext-item-transition.py <item> --to Review` | Status `Review`, otomatik git commit |
-| Final Review (request changes) | Item approver | `scripts/kortext-item-transition.py <item> --to "In Progress"` | Status `In Progress`, otomatik git commit |
-| Final Review (approve) | Item approver | `!approve` komutu (manuel) | +prime / approver onayı |
-| Deployment & Closing | +devops-engineer | `scripts/kortext-handover.py` → `scripts/kortext-item-check.py` → `scripts/kortext-item-transition.py --to Done` → `scripts/kortext-backlog-sync.py` | Handover, gate kontrol, `Done` geçişi, dashboard sync, git commit zinciri |
-
-> [!INFO] 
-> - Süreç başladığında ajanlar backlog item ID'leri üzerinden ilerler.
-> - Her ajan göreve başlarken `../workspace/memory/context/[agent-name]-active.md` dosyasını oluşturur veya günceller; görev bitince kendi aktif görev dosyasını siler.
-> - Karşılaşılan sorunların çözümleri ilgili ajan tarafından `../workspace/memory/learned.md` dosyasına işlenir.
-> - Süreçte `../rules/branching.md` kuralları uygulanır.
-> - Assignee ajan item dosyasının durumunu güncellemekten sorumludur.
-> - Crossroads: Geliştirme sırasında birden fazla çözüm yolu varsa:
-> 	- Seçenekler listelenir, öneri belirtilir
-> 	- +prime'a sunulur
-> 	- +prime karar vermeden inisiyatif alınmaz
-> - +prime yalnızca kendisine atanmış kontrol/onay işi olduğunda, Epic tamamlandığında veya büyük iş/kavşak/checkpoint durumunda bilgilendirilir.
-> - Ajanların kendi aralarındaki normal geliştirme, doğrulama ve düzeltme devrinde +prime'a bildirim verilmez.
-> - Checkpoint (kritik dönüm noktalarında): Önemli ve test edilebilir dönüm noktalarında (örn: "Login backend tamamlandı")
-> 	- Büyük işse veya +prime onayı gerekiyorsa +prime'a kısa durum özeti verilir.
-> 	- "devam" veya "onay" komutu beklenir.
-> 	- **İstisna:** Ardışık küçük backend görevlerinde (UI değişikliği içermeyen) onay istenmez.
-> 	- **UI değişikliği varsa:** Kod derinleşmeden önce tasarım yapısı açıklanır ve +prime onayı alınır.
-
-## Backlog Item Tipleri
-
-- **Epic:** `E` prefix'i ile takip edilir ve ortak iş hedefini temsil eder. Epic detayları `epic-dashboard.md` içinde tutulur.
-- **Task:** `T` prefix'i ile takip edilir. Yeni geliştirme veya planlı uygulama işidir.
-- **Bug:** `B` prefix'i ile takip edilir. Mevcut davranışın yanlış çalışmasıdır.
-- **Debt:** `D` prefix'i ile takip edilir. Teknik borç, refactor, mimari iyileştirme, test açığı veya operasyonel borçtur.
-
-## Backlog Dosya Yapısı
-
-Backlog tek seviyeli dosya yapısı kullanır. Version, Epic, Task, Bug ve Debt için ayrı klasör açılmaz.
-
-```text
-../workspace/memory/backlog/
-├── version-dashboard.md
-├── epic-dashboard.md
-├── debt-dashboard.md
-├── TXX-[task-name].md
-├── BXX-[bug-name].md
-└── DXX-[debt-name].md
-```
-
-## Item Akışları
-
-### Aşama (Status) Tanımları
-
-| Aşama | Açıklama |
-|---|---|
-| **To Do** | Sahibi belli ama sırası gelmemiş ya da blokeri çözülmemiş item'ların aşamasıdır. |
-| **In Progress** | Aktif olarak yürütülen item'ların aşamasıdır. Tamamlanınca Test'e taşınır. |
-| **Test** | Code review ve item dosyasındaki Review Gates kontrollerinin yürütüldüğü aşamadır. Tüm kontroller bitince Review'a taşınır. |
-| **Review** | +prime ya da yetkili ajanın nihai uygunluk değerlendirmesi yaptığı aşamadır. |
-| **Done** | Tüm doğrulama süreçlerinden geçmiş, approver tarafından onaylanmış item'ların aşamasıdır. |
-
-### Epic Workflow 
-
-To Do (Hazırlık) → In Progress (Geliştirme) → Done (Tamamlandı)
-- **Geliştirme:** Epic'e bağlı ilk Task veya Bug `In Progress` olduğunda Epic `epic-dashboard.md` içinde `In Progress` yapılır. Epic için ayrı klasör veya branch açılmaz; çalışma düz backlog item dosyaları ve item branch'leri üzerinden yürür.
-- **Tamamlandı:** Epic'e bağlı tüm Task ve Bug item'ları `Done` olduğunda Epic `Done` yapılır. Süreç bitiminde `../workspace/reports/status-reports.md` güncellenir.
-
-### Task Workflow
-
-To Do (Bekleme/Planlama) → In Progress (Uygulama) → Test (Doğrulama) → Review (Final Review) → Done (Kapanış)
-- **Bekleme:** Item backlog içerisinden seçilip rafine edilmiş olarak çalışılmayı bekler (To Do).
-- **Uygulama:** Item atanan ajan (Assignee) işi üzerine alır ve kodlama/tasarım sürecini gerçekleştirir (In Progress).
-- **Doğrulama:** Tamamlanan iş code review ve item dosyasındaki Review Gates kontrollerinden geçer. Hata varsa item `In Progress` olarak assignee ajana geri döner.
-- **Onay:** Doğrulama adımlarından başarıyla geçen iş Approver tarafına onay için sunulur (Review).
-- **Kapanış:** Onay (approve) alan iş `development` branch'ine merge edilir (Done).
-
-### Bug Workflow
-
-To Do (Tespit) → In Progress (Çözüm) → Test (Doğrulama) → Review → Done
-- **Tespit & Raporlama:** Bug tespit edildiğinde tespit eden ajan veya +engineering-manager `../workspace/memory/backlog/BXX-[bug-name].md` item dosyasını oluşturur ve bug'ı `epic-dashboard.md` içinde ilgili Epic satırıyla ilişkilendirir.
-- **Atama:** +engineering-manager ilgili Bug'ı çözecek doğru ajana atar.
-- **Çözüm:** İlgili ajan hatayı kodda çözer (In Progress).
-- **Doğrulama:** Kod, testi yapan kişiye geri döner (Test).
-- **Kapanış:** Doğrulanırsa Bug kapatılır (Done).
-
-### Debt Workflow
-
-To Do (Borç ekleme) → In Progress (Borç ödeme) → Test (Doğrulama) → Review → Done
-- **Borç ekleme:** Teknik borç tespit edildiğinde tespit eden ajan veya +engineering-manager `../workspace/memory/backlog/DXX-[debt-name].md` item dosyasını oluşturur ve borcu `debt-dashboard.md` içinde listeler.
-- **Atama:** +engineering-manager ilgili borcu ödeyecek doğru ajana atar.
-- **Çözüm:** İlgili ajan borcu öder (In Progress).
-- **Doğrulama:** Tamamlanan iş code review ve item dosyasındaki Review Gates kontrollerinden geçer. Hata varsa item `In Progress` olarak assignee ajana geri döner.
-- **Kapanış:** Onay (approve) alan iş `development` branch'ine merge edilir (Done).
-
-## Pick & Plan (İşi Alma)
-
-**Sorumlu:** Ajan (Assignee)
-1. `../workspace/memory/backlog/version-dashboard.md`, `../workspace/memory/backlog/epic-dashboard.md` ve `../workspace/memory/backlog/debt-dashboard.md` dosyalarından kendisine atanmış `To Do` item'ı bulur.
-2. İlgili `TXX-[task-name].md`, `BXX-[bug-name].md` veya `DXX-[debt-name].md` item dosyasını açar.
-3. Item dosyasındaki `Dependencies` bölümünü kontrol eder. `Blocked By` alanında tamamlanmamış item varsa işe başlamaz.
-4. `../scripts/kortext-item-start.py` aracıyla item statüsünü `In Progress` yapar ve `../workspace/memory/context/[agent-name]-active.md` dosyasını oluşturur veya günceller.
-
-> [!Example]
-> [+ajan] | [item-id] | In Progress | [DD.MM.YY-HH:MM]
-> [Item adı] — Implementation başlıyor
-   
-> [!TIP] Handoff: Yok — bu adım kendi içinde tamamlanır, ajan doğrudan **Implementation**'a geçer.
-
-## Implementation (Kodlama)
-
-**Sorumlu:** Ajan (Assignee)
-1. `../rules/branching.md` kuralına göre `feature/` branch'i açar.
-
-> [!TIP] Branching kuralına göre:
-> ```bash
-> git pull origin development
-> git checkout -b feature/[item-id]
-> ```
-> Branch ismi küçük harf, kebab-case ve item ID içermelidir. Örn: `feature/t01-login-form`
-
-2. `../workspace/references/` altındaki onaylı referanslara sadık kalarak işi uygular.
-3. Gerekli unit testleri yazar ve yerelde çalıştırır.
-4. Codebase'e commit atar. Commit mesajları `../workspace/references/dictionary.md` standartlarına uymalıdır.
-5. PR açar ve `../scripts/kortext-item-transition.py` aracıyla item statüsünü `Test` aşamasına taşır.
-> [!TIP] Handoff: PR açıldığında item dosyası `Test` yapılır ve ilgili doğrulama ajanlarına context aktarılır.
-
-## Verification (Doğrulama & Test)
-
-Bu aşamanın uygulama detayı `05-test-cycle.md` içinde tanımlanır. `04-development-cycle.md` yalnızca lifecycle geçişini tarif eder.
-
-1. PR açıldığında item dosyası `Test` statüsünde olmalıdır.
-2. Doğrulama süreci `05-test-cycle.md` standardına göre yürütülür.
-3. Test cycle başarısız olursa `../scripts/kortext-item-transition.py` aracıyla item `In Progress` statüsüne geri döner ve assignee ajana atanır.
-4. Test cycle başarılı olursa `../scripts/kortext-item-transition.py` aracıyla item `Review` statüsüne taşınır.
-
-> [!TIP]
-> Eğer item kritik bir özellikse veya +prime onayı gerektiriyorsa (UI onayı gibi), +prime'a atanır ve bildirim verilir.
-> Doğrulama detayları, gate sonuçları ve raporlama kuralları için tek kaynak `05-test-cycle.md` dosyasıdır.
-
-## Final Review (Son Kontrol)
-
-**Sorumlu:** Item approver
-1. Item dosyasındaki Acceptance Criteria, Review Gates sonuçları, PR ve test çıktıları incelenir.
-2. Hata varsa `Request Changes` verilir; item `In Progress` olarak assignee ajana geri döner.
-3. Item approver +prime ise kontrol işi +prime'a bildirilir ve onay beklenir.
-4. Hata yoksa item onaylanır ve +devops-engineer'a atanır.
-
-## Deployment & Closing (Kapanış)
-
-**Sorumlu:** +devops-engineer
-1. Onay verildiğinde PR `development` branch'ine merge edilir.
-2. CI/CD pipeline çalışır ve kod Staging ortamına çıkar.
-3. `../scripts/kortext-handover.py` aracıyla `../workspace/memory/handover.md` dosyasına yeni devir kaydı eklenir. Handover tamamlanmadan item `Done` yapılamaz.
-4. `../scripts/kortext-item-check.py` aracıyla acceptance criteria, review gates, handover ve context kapanışı kontrol edilir.
-5. `../scripts/kortext-item-transition.py` aracıyla item `Done` yapılır.
-6. `../scripts/kortext-backlog-sync.py` aracıyla dashboard drift kontrol edilir.
-7. `../workspace/memory/backlog/version-dashboard.md`, `../workspace/memory/backlog/epic-dashboard.md` veya `../workspace/memory/backlog/debt-dashboard.md` ilgili item statüsüne göre güncellenir.
-
-> [!TIP] Dosyanın en üstüne aşağıdaki alanlar doldurularak yeni bir kayıt eklenir:
-> - **Completed:** Ne yapıldı?
-> - **Changed Files:** Değiştirilen dosyalar ve ne değiştiği
-> - **Watch-outs & Decisions:** Bilinen kırılgan nokta veya workaround varsa
-> - **Last Commit:** Son commit hash ve mesajı
-> - **Next Steps:** Sıradaki ajan ne yapacak? (yoksa "Yok")
-   
-8. `../workspace/memory/context/[agent-name]-active.md` dosyasını siler. Başka ajanların aktif görev dosyalarına dokunmaz.
-
-## Bildirim
-
-Duruma göre yalnızca ilgili bildirimi gönder.
-
-> [!NOTE] PRIME KONTROLÜ BEKLENİYOR
-> +prime,
-> `../workspace/memory/backlog/[TXX|BXX|DXX]-[item-name].md` için Final Review sana atandı.
-> Acceptance Criteria, Review Gates sonuçları, PR ve test çıktıları hazır.
-> Doğruysa onayını bekliyorum.
-
-> [!NOTE] EPIC TAMAMLANDI
-> +prime,
-> `[epic-id]` tamamlandı.
-> `../workspace/reports/status-reports.md` güncellendi.
-
-> [!NOTE] CHECKPOINT
-> +prime,
-> `../workspace/memory/backlog/[TXX|BXX|DXX]-[item-name].md` için kritik dönüm noktasına gelindi.
-> [kısa durum özeti]
-> Devam için onayını bekliyorum.

package/workflows/05-test-cycle.md

@@ -1,123 +0,0 @@
-# Test Cycle
-
-Bu akış, `04-development-cycle.md` içindeki `Test` statüsünün nasıl yürütüleceğini tanımlar. Amaç, item'ın `Review` aşamasına geçmeden önce gerekli doğrulama kayıtlarını üretmek ve blokajları doğru ajana geri döndürmektir.
-
-## Girdi ve Çıkış
-
-- **Başlangıç koşulu:** Item dosyası `Test` statüsünde olmalı ve PR/CI çıktıları hazır bulunmalıdır.
-- **Girdi:** Item dosyası, acceptance criteria, review gates, PR ve CI kanıtları.
-- **Çıkış:** `../workspace/reports/test-reports.md` içinde doğrulama kaydı ve item için `In Progress` veya `Review` kararı.
-- **Sonraki akış:** Başarılıysa `04-development-cycle.md` içindeki Final Review adımı; başarısızsa item yeniden assignee ajana döner.
-
-## Otomasyon Çağrıları
-
-> [!TIP] Bu tablo workflow adımlarının hangi script/hook'a bağlandığını gösterir. Tek-kaynak referans: `../settings/INTEGRATION-MAP.md`.
-
-| Adım | Tetikleyici Persona | Script / Hook | Beklenen Çıktı |
-|---|---|---|---|
-| Test başlangıç (status doğrulama) | Doğrulayan ajan | `scripts/kortext-item-check.py <item>` | Acceptance Criteria + Review Gates kontrolü (read-only) |
-| Code review fail | +engineering-manager | `scripts/kortext-item-transition.py <item> --to "In Progress"` | Status `In Progress`, otomatik git commit |
-| Code review pass | +engineering-manager | (rapor `../workspace/reports/test-reports.md`'ye yazılır) | Test raporu güncel |
-| Quality control gate | +qa-engineer | (gate sonucu test-reports.md) | Gate sonuç kaydı |
-| Security check gate | +security-engineer | (gate sonucu test-reports.md + gerekirse security-reports.md) | Gate sonuç kaydı |
-| Design review gate | +designer | (gate sonucu test-reports.md) | Gate sonuç kaydı |
-| Herhangi gate fail | Gate sahibi ajan | `scripts/kortext-item-transition.py <item> --to "In Progress"` | Status `In Progress`, otomatik git commit |
-| Tüm gate'ler pass | Son gate ajanı | `scripts/kortext-item-transition.py <item> --to Review` | Status `Review`, otomatik git commit |
-
-## Genel Prensipler
-
-- Test cycle yalnızca item dosyası `Test` statüsündeyken çalışır.
-- Test sonuçlarının ana kaydı `../workspace/reports/test-reports.md` dosyasına yazılır.
-- Code review her item için zorunludur.
-- `Quality control`, `Security check` ve `Design review` yalnızca item dosyasındaki `Review Gates` içinde işaretliyse çalıştırılır.
-- Başarısız doğrulama varsa item `In Progress` yapılır ve assignee ajana geri atanır.
-- +prime yalnızca kendisine atanmış kontrol/onay işi olduğunda, büyük/kritik blokajda veya kavşak durumunda bilgilendirilir.
-
-## Girdi
-
-- `../workspace/memory/backlog/[TXX|BXX|DXX]-[item-name].md`
-- PR linki ve CI çıktıları
-- Item dosyasındaki `Acceptance Criteria`
-- Item dosyasındaki `Review Gates`
-- Gerekli referans dosyaları: `../workspace/references/`
-
-## Test Katmanları
-
-### Local Checks
-
-**Sorumlu:** Assignee ajan
-
-Bu kontroller assignee ajan tarafından PR açılmadan önce tamamlanmış olmalıdır. Test cycle içinde bu kayıtların varlığı kontrol edilir:
-- Linting
-- Unit tests
-- Statik analiz veya type check
-- Değişiklik kapsamındaki minimum manuel doğrulama
-
-### Pull Request / CI
-
-**Sorumlu:** +engineering-manager
-
-PR açıldığında aşağıdaki kontroller incelenir:
-- Build sonucu
-- Unit/integration test sonucu
-- CI logları
-- Kodun referans dosyalarına ve proje standartlarına uygunluğu
-
-### Review Gates
-
-| Gate | Sorumlu | Çıktı |
-|---|---|---|
-| Code review | +engineering-manager | `../workspace/reports/test-reports.md` |
-| Quality control | +qa-engineer | `../workspace/reports/test-reports.md` |
-| Security check | +security-engineer | `../workspace/reports/test-reports.md` |
-| Design review | +designer | `../workspace/reports/test-reports.md` |
-
-> [!NOTE]
-> `Security check` sonucunda ayrıntılı güvenlik kaydı gerekiyorsa ek detay `../workspace/reports/security-reports.md` dosyasına yazılır. Ana geçiş kararı yine `../workspace/reports/test-reports.md` içinde özetlenir.
-
-## Akış
-
-1. Item dosyasının `Status` alanının `Test` olduğunu doğrula.
-2. Item dosyasındaki `Acceptance Criteria` maddelerini oku.
-3. Item dosyasındaki `Review Gates` maddelerini oku.
-4. PR ve CI sonuçlarını incele.
-5. Code review sonucunu `../workspace/reports/test-reports.md` dosyasına yaz.
-6. Code review başarısızsa `../scripts/kortext-item-transition.py` aracıyla item'ı `In Progress` yap ve assignee ajana geri ata.
-7. Code review başarılıysa işaretli `Quality control`, `Security check` ve `Design review` gate'leri ilgili ajanlara yönlendir.
-8. Code review sonrası gate'ler birbirinden bağımsızsa paralel yürütülebilir.
-9. Her gate sonucu `../workspace/reports/test-reports.md` dosyasına yazılır.
-10. Herhangi bir gate başarısızsa:
-   - `../scripts/kortext-item-transition.py` aracıyla item dosyasını `In Progress` yap.
-   - Hata listesini item dosyasındaki `Work Log` veya `Notes` alanına ekle.
-   - Item'ı assignee ajana geri ata.
-11. Tüm zorunlu kontroller geçerse `../scripts/kortext-item-transition.py` aracıyla item dosyasını `Review` statüsüne taşı.
-12. `../workspace/memory/context/[agent-name]-active.md` dosyasını ilgili doğrulama ajanı günceller.
-
-## Blokaj Kuralı
-
-Normal test hataları +prime'a bildirilmez. Ajanlar arası düzeltme döngüsü içinde çözülür.
-
-+prime'a yalnızca şu durumlarda bildirim verilir:
-- Blokaj item kapsamını değiştiriyorsa.
-- Çözüm için birden fazla yol varsa ve karar gerekiyorsa.
-- Risk büyük/kritik olarak işaretlendiyse.
-- Final Review veya özel onay +prime'a atanmışsa.
-
-## Bildirim
-
-Normal test fail için bildirim gönderme. Item `In Progress` yapılır, assignee ajana geri atanır ve detaylar `../workspace/reports/test-reports.md` içine yazılır.
-
-Duruma göre yalnızca ilgili bildirimi gönder:
-
-> [!NOTE] TEST BLOKAJI
-> +prime,
-> `../workspace/memory/backlog/[TXX|BXX|DXX]-[item-name].md` test aşamasında karar gerektiren blokaja girdi.
-> Rapor: `../workspace/reports/test-reports.md`
-> Karar: [kısa karar konusu]
-> Komutunu bekliyorum.
-
-> [!NOTE] PRIME KONTROLÜ BEKLENİYOR
-> +prime,
-> `../workspace/memory/backlog/[TXX|BXX|DXX]-[item-name].md` için test kontrolü sana atandı.
-> Rapor: `../workspace/reports/test-reports.md`
-> Doğruysa onayını bekliyorum.