kortext 2.2.3 → 3.1.0

package/workflows/00-kortext-setup.md

@@ -1,53 +0,0 @@
-# Kortext Setup
-
-Bu akış Kortext'i hedef projede başlatır, sistem dosyalarını korur ve ilk çalışma kararını +prime'a bildirir.
-
-## Girdi ve Çıkış
-
-- **Başlangıç koşulu:** Kortext dosya ağacı hedef projeye eklenmiş olmalıdır.
-- **Girdi:** `../workspace/references/blueprint.md`
-- **Çıkış:** Kilitlenmiş framework çekirdeği ve +prime için bir sonraki akış kararı.
-- **Sonraki akış:** Yeni proje için `01a-analysis-pipeline.md`, mevcut proje için `01b-onboarding-pipeline.md`.
-
-## Koruma
-
-1. Başka hiçbir işlem yapmadan önce `../scripts/lock_kortext.sh` dosyasını çalıştır.
-2. Aşağıdaki Kortext sistem dosyalarını ve dizinlerini salt okunur yap:
-	- `../AGENTS.md`
-	- `../agents/`
-	- `../rules/`
-	- `../workflows/`
-	- `../hooks/`
-	- `../scripts/`
-
-## Anayasanın Yüklenmesi
-
-3. Kortext protokollerini ve davranış kurallarını içeren şu dosyaları oku:
-	- `../rules/behavior.md`
-	- `../rules/commands.md`
-
-## Durum Tespiti
-
-4. Kortext dizin yapısının doğru olup olmadığını ve güncel olup olmadığını kontrol et.
-
-> [!WARNING] BLUEPRINT KOŞULU
-> `../workspace/references/blueprint.md` boşsa sistem ilerlemez.
-
-5. `../workspace/references/blueprint.md` dosyasını kontrol et.
-	- Blueprint boşsa süreci durdur ve +prime'dan blueprint'i tamamlamasını iste.
-	- Blueprint doluysa Kortext kurulumu tamamlanır; yeni proje analizi veya mevcut proje onboarding kararı +prime komutuyla verilir.
-	- Yeni proje için `01a-analysis-pipeline.md` akışı kullanılır.
-	- Mevcut projeyi Kortext'e adapte etmek için `01b-onboarding-pipeline.md` akışı kullanılır.
-
-## Bildirim
-
-Duruma göre yalnızca ilgili bildirimi kullan.
-
-> [!NOTE] KORTEXT [DURDU/YÜKLENDİ]
-> +prime,
-> [`../workspace/references/blueprint.md` boş olduğu için kurulumu ilerletmiyorum.
-> Blueprint'i tamamladıktan sonra `!setup kortext` komutunu bekliyorum.]
-> [Kortext yüklendi ve [project-name] projesi için hazır.
-> Yeni projenin analizi için `!start analysis` komutunu bekliyorum.]
-> [Kortext yüklendi ve [project-name] projesi için hazır.
-> Mevcut projeyi Kortext'e adapte etmek için `!start onboard` komutunu bekliyorum.]

package/workflows/01a-analysis-pipeline.md

@@ -1,117 +0,0 @@
-# Analysis Pipeline (`!start analysis`)
-
-Bu akış, yeni bir projenin ürün, teknik ve kalite temelini oluşturur.
-
-## Girdi ve Çıkış
-
-- **Başlangıç koşulu:** `../workspace/references/blueprint.md` dolu ve onaylı olmalıdır.
-- **Girdi:** Onaylı blueprint.
-- **Çıkış:** Ürün, teknik ve test referansları ile `../workspace/reports/analysis-reports.md`.
-- **Sonraki akış:** Onay sonrası `02-planning-pipeline.md`.
-
-> [!TIP]
-> - Birbirine bağımlı olmayan adımlarda (Örn: +security-engineer ve +designer) ajanlar eşzamanlı (paralel) olarak çalışır.
-> - Input dosyaların `status: approved` olması gerekir. Değilse, ilgili `approver`'dan dosyayı incelemesi istenir.
-> - Her ajan bir adıma başlamadan önce `../workspace/memory/context/[agent-name]-active.md` dosyasını oluşturur veya günceller; adım bitince sonucu `../workspace/memory/handover.md` dosyasına kaydeder ve kendi aktif görev dosyasını siler.
-
-## Ön Hazırlıklar
-
-**+operation-manager**
-1. `../workspace/memory/context/operation-manager-active.md` dosyasını oluşturur veya günceller.
-2. Bu workflow'u okur ve paralel çalışabilecek ajanları belirler.
-3. `../rules/models.md` dosyasını okur ve görevli her ajanın kullanacağı LLM/model eşleşmesini belirler.
-4. Ajanlara görevlerini verir.
-
-## Product Analysis
-
-1. **+compliance-expert:** Projenin bulunduğu sektöre, hedef pazarlara ve veri işleme biçimine göre yasal gereksinimleri belirler. KVKK, GDPR, CCPA gibi regülasyonları; gizlilik, aydınlatma, rıza, saklama, silme ve üçüncü taraf veri paylaşımı açısından değerlendirir.
-	- Inputs: `../workspace/references/blueprint.md`
-	- Outputs: `../workspace/references/legal-strategy.md`
-	- Approver: +prime
-2. **+growth-expert:** Hedef kitleye, pazara ve ürün vaadine göre büyüme stratejisini belirler. SEO/GEO, kanal stratejisi, ölçümleme, analitik ve dönüşüm takibi için gerekli görevleri çıkarır.
-	- Inputs: `../workspace/references/blueprint.md`
-	- Outputs: `../workspace/references/growth-strategy.md`
-	- Approver: +prime
-3. **+product-manager:** Blueprint'i, legal ve growth çıktılarını birleştirerek ürün gereksinimlerini çıkarır. Kapsamı, kullanıcı tiplerini, ana akışları, öncelikleri, kabul kriterlerini ve kapsam dışı bırakılan işleri netleştirir.
-	- Inputs: `../workspace/references/blueprint.md`, `../workspace/references/legal-strategy.md`, `../workspace/references/growth-strategy.md`
-	- Outputs: `../workspace/reports/product-requirements.md`
-	- Approver: +prime
-
-### Ara Bildirim
-
-> [!NOTE] RAPOR HAZIR
-> +prime, 
-> - `../workspace/references/legal-strategy.md`
-> - `../workspace/references/growth-strategy.md`
-> - `../workspace/reports/product-requirements.md`
-> raporları hazır. `!approve/reject [report-name]` komutunu bekliyorum.
-
-4. **+copywriter:** Ürün gereksinimleri, yasal sınırlar ve büyüme stratejisine göre içerik stratejisini oluşturur. Marka dili, mesaj hiyerarşisi, sayfa içerikleri, mikro metinler ve kampanya/SEO içerik yönünü belirler.
-	- Inputs: `../workspace/reports/product-requirements.md`, `../workspace/references/legal-strategy.md`, `../workspace/references/growth-strategy.md`
-	- Outputs: `../workspace/references/content-strategy.md`
-	- Approver: +prime
-
-### Ara Bildirim
-
-> [!NOTE] RAPOR HAZIR
-> +prime, 
-> `../workspace/references/content-strategy.md` raporu hazır. `!approve/reject content-strategy` komutunu bekliyorum.
-
-## Technical Analysis
-
-1. **+engineering-manager:** Teknoloji yığınını (stack), MCP sunucularını, geliştirme araçlarını ve +prime tarafından kurulması gereken ön gereksinimleri belirler. Bu ön gereksinimler test cihazları, emulator, API key gerektiren servis hesapları veya harici araçlar olabilir. Kodlama standartlarını ve proje klasör yapısı kurallarını yazar.
-	- Inputs: `../workspace/references/blueprint.md`, `../workspace/reports/product-requirements.md`
-	- Outputs: `../workspace/references/tech-stack.md`, `../workspace/references/dictionary.md`, `../workspace/references/file-system.md`
-	- Approver: +prime
-2. **+security-engineer:** Seçilen tech stack'in bilinen güvenlik risklerini ve proje verisinin hassasiyetini değerlendirir. Kimlik doğrulama, yetkilendirme, secret yönetimi, veri saklama, loglama, `.gitignore` ve güvenli geliştirme kurallarını belirler.
-	- Inputs: `../workspace/references/tech-stack.md`
-	- Outputs: `../workspace/references/security-rules.md`
-	- Approver: +engineering-manager
-3. **+designer:** Ürün gereksinimleri, içerik stratejisi ve teknik sınırları dikkate alarak tasarım sistemini oluşturur. Renk paleti, tipografi, bileşen ilkeleri, responsive davranış, erişilebilirlik ve temel UI kurallarını belirler.
-	- Inputs: `../workspace/reports/product-requirements.md`, `../workspace/references/tech-stack.md`, `../workspace/references/content-strategy.md`
-	- Outputs: `../workspace/references/design-system.md`
-	- Reviewer: +frontend-developer
-	- Approver: +prime
-
-### Ara Bildirim
-
-> [!NOTE] RAPOR HAZIR
-> +prime, 
-> `../workspace/references/design-system.md` raporu hazır. `!approve/reject design-system` komutunu bekliyorum.
-
-4. **+db-admin:** Ürün gereksinimleri, güvenlik kuralları ve teknik standartlara göre veritabanı şemasını tasarlar. Tabloları, ilişkileri, indeksleri, erişim kurallarını, migration yaklaşımını ve veri bütünlüğü gereksinimlerini netleştirir.
-	- Inputs: `../workspace/reports/product-requirements.md`, `../workspace/references/security-rules.md`, `../workspace/references/dictionary.md`, `../workspace/references/file-system.md`, `../workspace/references/tech-stack.md`
-	- Outputs: `../workspace/references/db-schema.md`
-	- Approver: +engineering-manager
-5. **+engineering-manager:** API uçlarını ve servis sınırlarını tasarlar. Teknik standartları, endpoint listesini, istek/yanıt modellerini, hata formatlarını, yetkilendirme gereksinimlerini ve veri akışını belirler.
-	- Inputs: `../workspace/reports/product-requirements.md`, `../workspace/references/security-rules.md`, `../workspace/references/dictionary.md`, `../workspace/references/file-system.md`, `../workspace/references/tech-stack.md`, `../workspace/references/db-schema.md`
-	- Outputs: `../workspace/references/api-reference.md`
-	- Reviewer: +backend-developer
-	- Approver: +engineering-manager
-6. **+engineering-manager:** Teknik analiz çıktılarını konsolide ederek teknik gereksinim raporunu oluşturur. Stack, dosya yapısı, güvenlik, veritabanı, API, tasarım sistemi ve uygulanması gereken mühendislik kararlarını tek kaynakta toplar.
-	- Inputs: `../workspace/reports/product-requirements.md`, `../workspace/references/security-rules.md`, `../workspace/references/dictionary.md`, `../workspace/references/file-system.md`, `../workspace/references/tech-stack.md`, `../workspace/references/db-schema.md`, `../workspace/references/api-reference.md`, `../workspace/references/design-system.md`
-	- Outputs: `../workspace/reports/tech-requirements.md`
-	- Approver: +prime
-7. **+qa-engineer:** Ürün ve teknik gereksinimlere göre test stratejisini belirler. Test türlerini, kritik kullanıcı akışlarını, otomasyon kapsamını, manuel QA ihtiyaçlarını, kabul kriterlerini ve release öncesi kalite kapılarını tanımlar.
-	- Inputs: `../workspace/reports/product-requirements.md`, `../workspace/reports/tech-requirements.md`
-	- Outputs: `../workspace/references/test-strategy.md`
-	- Approver: +engineering-manager
-
-## Konsolidasyon
-
-> [!NOTE]
-> - Tüm output dosyaları ilgili reviewer/approver tarafından onaylandıktan sonra konsolidasyon başlar.
-> - +prime'ın karar vermesi gereken açık konular `../workspace/reports/analysis-reports.md` içinde ayrı bir karar listesi olarak yazılır.
-
-8. **+operation-manager:** Product, technical ve test çıktılarını konsolide ederek nihai analiz raporunu oluşturur. Rapor; proje kapsamını, ana kararları, onay bekleyen konuları, riskleri, bağımlılıkları ve planlama akışına aktarılacak görev başlıklarını netleştirir.
-	- Inputs: `../workspace/reports/product-requirements.md`, `../workspace/reports/tech-requirements.md`, `../workspace/references/test-strategy.md`
-	- Outputs: `../workspace/reports/analysis-reports.md`
-	- Approver: +prime
-
-## Bildirim
-
-> [!NOTE] ANALİZ TAMAMLANDI
-> +prime, 
-> [project-name] analizi tamamlandı. 
-> `../workspace/reports/analysis-reports.md` dosyası için `!approve/reject analysis-reports` komutunu bekliyorum.
-> Onaydan sonra planlama akışı için `!start planning` komutunu bekleyeceğim.

package/workflows/01b-onboarding-pipeline.md

@@ -1,110 +0,0 @@
-# Onboarding Pipeline (`!start onboard`)
-
-Bu akış mevcut bir projeyi Kortext çalışma düzenine dahil eder.
-
-## Girdi ve Çıkış
-
-- **Başlangıç koşulu:** Mevcut codebase erişilebilir olmalı ve +prime başlangıç özetini `../workspace/references/blueprint.md` içine yazmış olmalıdır.
-- **Girdi:** Mevcut codebase, başlangıç blueprint'i ve varsa mevcut proje dokümanları.
-- **Çıkış:** Mevcut sistemin referans dosyaları, teknik borç görünümü ve `../workspace/reports/analysis-reports.md`.
-- **Sonraki akış:** Onay sonrası `02-planning-pipeline.md`.
-
-> [!TIP]
-> - Birbirine bağımlı olmayan keşif adımlarında ajanlar eşzamanlı (paralel) çalışır.
-> - Her ajan bir adıma başlamadan önce `../workspace/memory/context/[agent-name]-active.md` dosyasını oluşturur veya günceller; adım bitince sonucu `../workspace/memory/handover.md` dosyasına kaydeder ve kendi aktif görev dosyasını siler.
-
-**Ön koşul:** +prime, `../workspace/references/blueprint.md` dosyasına yalnızca başlangıç özetini yazar:
-- Projenin ne olduğu ve mevcut durumu
-- Hangi versiyonda olduğu (örn: v2.3, beta, production)
-- Bilinen kritik teknik borçlar veya sorunlar
-- Kısa vadeli hedef (neden Kortext'e alınıyor?)
-
-Onboarding sırasında +prime'a sorulan tüm ek soruların yanıtları `../workspace/reports/analysis-reports.md` içinde toplanır. Bu yanıtlar planlama aşamasında backlog kararlarına girdi olur.
-
----
-
-## 1. Teknik Keşif
-
-1. **+engineering-manager:** Mevcut codebase'i okuyarak teknoloji yığınını, klasör yapısını, dosya organizasyonunu, bağımlılıkları, dil/framework versiyonlarını, isimlendirme kurallarını ve mimari kalıpları tespit eder. Amaç yeni standart dayatmak değil, projenin mevcut teknik gerçekliğini belgelemektir.
-	- Inputs: Mevcut codebase, bağımlılık dosyaları, framework konfigürasyonları
-	- Outputs: `../workspace/references/tech-stack.md`, `../workspace/references/file-system.md`, `../workspace/references/dictionary.md`
-	- Approver: +prime
-2. **+db-admin:** Mevcut migration dosyalarını, şema tanımlarını, ORM modellerini ve veritabanı bağlantı biçimini inceler. Tabloları, ilişkileri, index'leri, veri tiplerini ve veri bütünlüğü kurallarını belgeler.
-	- Inputs: Mevcut migration/schema dosyaları, ORM modelleri, veritabanı konfigürasyonları
-	- Outputs: `../workspace/references/db-schema.md`
-	- Approver: +engineering-manager
-3. **+security-engineer:** Mevcut güvenlik yapılandırmalarını inceler. Auth, yetkilendirme, middleware, env handling, CORS, rate limiting, secret yönetimi, loglama ve hassas veri kullanımı açısından açıkları veya eksik katmanları tespit eder.
-	- Inputs: Mevcut codebase, `../workspace/references/tech-stack.md`
-	- Outputs: `../workspace/references/security-rules.md`
-	- Approver: +engineering-manager
-	- Escalation: Kritik güvenlik bulguları +prime'a bildirilir.
-4. **+devops-engineer:** Mevcut CI/CD pipeline'larını, deployment süreçlerini, ortam yapılandırmalarını, branch stratejisini, erişim sahipliğini ve secret yönetimini inceler. Kortext'in `../rules/branching.md` kurallarıyla uyumsuzlukları ve release risklerini raporlar.
-	- Inputs: Mevcut CI/CD konfigürasyonları, deployment dosyaları, branch/release dokümantasyonu
-	- Outputs: `../workspace/references/access.md`, `../workspace/reports/delivery-reports.md`
-	- Approver: +delivery-manager
-
----
-
-## 2. Ürün ve API Keşfi
-
-1. **+engineering-manager:** Mevcut API endpoint'lerini, servis sınırlarını, request/response modellerini, auth mekanizmalarını ve entegrasyon noktalarını belgeler. +backend-developer teknik doğruluk açısından review yapar.
-	- Inputs: Mevcut route/controller dosyaları, servis katmanı, varsa Swagger/Postman koleksiyonu
-	- Outputs: `../workspace/references/api-reference.md`
-	- Reviewer: +backend-developer
-	- Approver: +engineering-manager
-2. **+product-manager:** Mevcut özellikleri, kullanıcı akışlarını, roller/izinleri, bilinen eksiklikleri ve var olan roadmap/issue listesini inceler. Ürünün şu an ne yaptığı ile +prime'ın beklentisi arasındaki farkları görünür yapar.
-	- Inputs: `../workspace/references/blueprint.md`, mevcut ürün dokümanları, issue tracker, roadmap, kullanıcı geri bildirimleri
-	- Outputs: `../workspace/reports/product-requirements.md`
-	- Approver: +prime
-3. **+qa-engineer:** Mevcut test kapsamını, test tiplerini, CI test raporlarını ve eksik test alanlarını belgeler. Kritik kullanıcı akışları için mevcut kalite güvencesinin yeterli olup olmadığını değerlendirir.
-	- Inputs: Mevcut test dosyaları, CI test raporları, `../workspace/reports/product-requirements.md`
-	- Outputs: `../workspace/references/test-strategy.md`
-	- Approver: +engineering-manager
-
----
-
-## 3. Teknik Borç Tespiti
-
-1. **+engineering-manager:** Keşif adımlarında tespit edilen teknik borçları, mimari sorunları, güvenlik risklerini, test açıklarını, devops/release risklerini ve iyileştirme alanlarını konsolide eder. Her borç kalemi için etki, risk, bağımlılık ve öncelik seviyesi belirler.
-	- Inputs: Tüm keşif çıktıları
-	- Outputs: `../workspace/reports/tech-requirements.md`
-	- Reviewer: +security-engineer, +qa-engineer, +devops-engineer
-	- Approver: +prime
-
----
-
-## 4. Talep Toplama
-
-Konsolidasyon başlamadan önce +prime'ın beklentileri ve açık kararları sisteme alınır.
-
-1. **+product-manager:** +prime'a planlama kararlarını etkileyecek ek soruları yöneltir. Amaç yeni rapor üretmek değil, backlog'a girecek öncelikleri ve yarım kalan işleri netleştirmektir.
-	- Sorular:
-		- Teknik borçlara ek olarak backlog'a alınmasını istediğin yeni özellikler var mı?
-		- Devam eden veya yarım kalmış görevler var mı? Bunlar nasıl önceliklendirilmeli?
-		- Kısa vadeli hedefin nedir? Örneğin belirli bir özelliği bitirmek, bir versiyonu yayınlamak veya sistemi stabilize etmek.
-	- Outputs: +prime yanıtları `../workspace/reports/analysis-reports.md` içinde `+prime Kararları ve Planlama Girdileri` başlığı altında konsolide edilir.
-	- Approver: +prime
-
-### Ara Bildirim
-
-> [!NOTE] TALEPLER ALINDI
-> +prime,
-> Yanıtların `../workspace/reports/analysis-reports.md` içine `+prime Kararları ve Planlama Girdileri` başlığı altında işlendi.
-> Doğruysa `!approve`, düzeltmek istersen `!reject [not]` komutunu bekliyorum.
----
-
-## 5. Konsolidasyon ve Onay
-
-1. **+operation-manager:** Tüm keşif çıktılarını, teknik borç listesini ve +prime yanıtlarını konsolide ederek onboarding analiz raporunu oluşturur. Rapor mevcut durum özetini, referans dosyalarını, riskleri, açık kararları, teknik borçları ve planning akışına aktarılacak başlıkları netleştirir.
-	- Inputs: Tüm keşif çıktıları, `../workspace/references/blueprint.md`, `../workspace/reports/tech-requirements.md`, +prime yanıtları
-	- Outputs: `../workspace/reports/analysis-reports.md`
-	- Approver: +prime
----
-
-## Bildirim
-
-> [!NOTE] ONBOARDING TAMAMLANDI
-> +prime,
-> [project-name] projesi Kortext'e dahil edildi.
-> `../workspace/reports/analysis-reports.md` dosyası için `!approve/reject analysis-reports` komutunu bekliyorum.
-> Onaydan sonra planning akışı için `!start planning` komutunu bekleyeceğim.

package/workflows/02-planning-pipeline.md

@@ -1,146 +0,0 @@
-# Planning Pipeline (`!start planning`)
-
-Bu akış, onaylı analiz çıktılarından uygulanabilir düz backlog yapısını üretir.
-
-## Girdi ve Çıkış
-
-- **Başlangıç koşulu:** `../workspace/reports/analysis-reports.md` onaylı olmalıdır.
-- **Girdi:** Analiz raporu ve bu raporda referans verilen onaylı kaynak dosyalar.
-- **Çıkış:** `../workspace/memory/backlog/` altında düz dashboard ve item dosyaları.
-- **Sonraki akış:** Ortam hazır değilse `03-environment-setup.md`, hazırsa `04-development-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ı |
-|---|---|---|---|
-| Görev Belirleme (toplu) | +engineering-manager | `scripts/kortext-bulk-plan.py <plan.json>` | Toplu Task/Bug/Debt item dosyaları + dashboard satırları, otomatik git commit |
-| Görev Belirleme (iteratif) | +engineering-manager | `scripts/kortext-backlog-add.py --type task|bug|debt --id <id> --title "..." --epic <epic-id>` | Item dosyası + dashboard satırı, otomatik git commit |
-| Spike Item Açma | +engineering-manager | `scripts/kortext-backlog-add.py --type spike --id S01 --title "..."` (workflows/02b ile birlikte) | Spike item + ADR placeholder |
-| Kalite & Etiketleme | +qa-engineer, +security-engineer, +designer | (item dosyalarına `Review Gates` eklenir; manuel düzenleme) | Gate işaretleri |
-| Bağımlılık & Önceliklendirme | +engineering-manager | (item dosyalarına `Blocks` / `Blocked By` eklenir; manuel düzenleme) | İlişki haritası |
-| Versiyonlama | +engineering-manager | (`version-dashboard.md` güncellenir) | Version eşleme |
-| Görev Atama + Model Seçimi | +engineering-manager + +operation-manager | (item dosyalarına `Assignee` + `Model` eklenir) | Atama tamam |
-| Konsolidasyon | +operation-manager | `scripts/kortext-backlog-sync.py` | Dashboard drift = 0 |
-| Onay | +prime | `!approve backlog` / `!reject backlog` (manuel) | Backlog kabul kaydı |
-
-> [!TIP]
-> - Birbirine bağımlı olmayan adımlarda (Örn: +security-engineer ve +qa-engineer) ajanlar eşzamanlı (paralel) olarak çalışır.
-> - Input dosyaların `status: approved` olması gerekir. Değilse, ilgili `approver`'dan dosyayı incelemesi istenir.
-> - Her ajan bir adıma başlamadan önce `../workspace/memory/context/[agent-name]-active.md` dosyasını oluşturur veya günceller; adım bitince sonucu `../workspace/memory/handover.md` dosyasına kaydeder ve kendi aktif görev dosyasını siler.
-> - **Metodoloji:** Kanban (Sprint yok, Eforlama yok)
-> - **Görev Tipleri:** Epic, Task, Bug, Debt
-> - **Inputs:** `../workspace/reports/analysis-reports.md` ve bu raporda onaylı olarak referans verilen tüm `../workspace/references/` ve `../workspace/reports/` çıktıları.
-> - **Outputs:** `../workspace/memory/backlog/` altında tek seviyeli dashboard ve item dosyaları
-
-## Görev Tipleri
-
-- **Epic:** Ortak bir iş hedefine hizmet eden görev grubu.
-- **Task:** Yeni geliştirme veya planlı iş.
-- **Bug:** Mevcut davranışın yanlış çalışması.
-- **Debt:** Bilinen teknik borç, refactor, mimari iyileştirme, test açığı veya operasyonel borç.
-
-## Review Gates
-
-- **Quality control:** QA kontrolü gerektiren görevlerde kullanılır.
-- **Security check:** Güvenlik incelemesi gerektiren görevlerde kullanılır.
-- **Design review:** UI veya UX doğrulaması gerektiren görevlerde kullanılır.
-
-## 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
-```
-
-- `version-dashboard.md`: Versiyon hedefleri, versiyon kapsamındaki Epic'ler ve genel ilerleme.
-- `epic-dashboard.md`: Epic listesi, Epic owner bilgisi, Epic altındaki Task/Bug ilişkileri ve Epic statüsü.
-- `debt-dashboard.md`: Debt listesi, assignee ve statü.
-- `TXX-[task-name].md`: Task detay dosyası.
-- `BXX-[bug-name].md`: Bug detay dosyası.
-- `DXX-[debt-name].md`: Debt detay dosyası.
-
-## Görev Belirleme
-
-1. **+engineering-manager:** Onaylı analiz çıktılarını tarayarak özellikleri, teknik gereksinimleri, açık riskleri ve +prime kararlarını backlog adaylarına dönüştürür.
-2. Her işi atomik seviyeye böler. Atomik iş tek başına anlaşılabilir, bağımsız geliştirilebilir ve ayrı doğrulanabilir olmalıdır.
-3. Her backlog adayı için görev tipini belirler:
-	- **Task:** Yeni geliştirme veya planlı uygulama işi.
-	- **Bug:** Mevcut davranışın yanlış çalışması.
-	- **Debt:** Teknik borç, refactor, mimari iyileştirme, test açığı veya operasyonel borç.
-4. Her görev için kısa açıklama, gereksinimler, beklenen çıktı ve kaynak referansını yazar.
-5. İnsan müdahalesi gerektiren işler +prime'a atanır. Bu işler domain satın alma, hesap açma, API key oluşturma, fiziksel cihaz kurulumu, platform erişimi veya bütçe/onay gerektiren kararlar olabilir.
-
-## Kalite ve Etiketleme
-
-1. **+qa-engineer:** Tüm Task, Bug ve Debt adaylarını inceler. Her görev için davranış odaklı, test edilebilir ve madde madde yazılmış Acceptance Criteria ekler.
-2. Test edilemeyecek kadar muğlak görevleri +engineering-manager'a revizyon için geri gönderir.
-3. QA kontrolü gerektiren görevlere `Review Gates: Quality control` ekler.
-4. **+security-engineer:** Güvenlik, auth, secret, veri işleme, erişim kontrolü veya compliance riski taşıyan görevlere `Review Gates: Security check` ekler.
-5. **+designer:** UI, UX, responsive davranış, erişilebilirlik veya görsel tutarlılık gerektiren görevlere `Review Gates: Design review` ekler.
-
-## Bağımlılık ve Önceliklendirme
-
-### İlişkilendirme
-
-1. **+engineering-manager:** Tüm görev adayları arasındaki teknik ve operasyonel bağımlılıkları belirler.
-2. Bir görevin başlaması için başka bir görevin tamamlanması gerekiyorsa `Blocks` ve `Blocked By` alanlarını kullanır.
-> [!INFO] **Bağımlılık Yönetimi Kuralı:**
-> - **Task A:** `Blocks: [Task B]`
-> - **Task B:** `Blocked By: [Task A]`
-> - Assignee kim olursa olsun, `Blocked By` alanındaki görev tamamlanmadan bağlı görev başlamaz.
-
-### Epic Kategorileri
-
-1. **+engineering-manager:** Atomik görevleri ortak bir iş hedefine hizmet eden Epic başlıkları altında birleştirir.
-2. Her Epic için amaç, kapsam, başarı kriteri, kapsadığı görev tipleri ve genel işleyiş yazılır.
-> [!WARNING] Her görev mutlaka bir **Epic** ile ilişkilendirilir.
-
-### Versiyonlama
-
-1. **+engineering-manager:** Epic'lerin ve görevlerin hangi versiyona ait olduğunu belirler.
-2. Epic'leri projenin karmaşıklığına göre `v0.x` aşamalarından başlayarak `v1.0` aşamasına kadar mantıksal bir sıraya dizer.
-3. Her versiyon için ana hedef, başarı kriteri ve kapsadığı Epic/Debt alanları yazılır.
-4. Versiyon bilgisi `version-dashboard.md` içinde tutulur; versiyonlara göre alt klasör açılmaz.
-5. Teknik borçlar `debt-dashboard.md` ve `DXX-[debt-name].md` item dosyalarında Debt olarak tutulur.
-> [!WARNING] Her epic mutlaka en az bir **Version** ile ilişkilendirilir.
-
-## Görev Atama, Model ve Skill Seçimi
-
-1. **+engineering-manager:** Her görevi yapması gereken ajana atar. Teknik görevlerde ajan seçimi görevin uzmanlık alanına, `../workspace/references/tech-stack.md` içeriğine ve gerekli Review Gates alanlarına göre yapılır.
-2. Her göreve uygulanması gereken skill bilgisini ekler. Skill seçimi teknoloji yığınına, görev tipine ve ilgili ajan rolüne göre yapılır.
-3. İnsan müdahalesi, erişim, bütçe veya dış platform onayı gerektiren görevler +prime'a atanır.
-4. **+operation-manager:** `../rules/models.md` dosyasına göre her görevin ihtiyaç duyduğu model tercihini belirler ve task içine ekler.
-5. Her Epic için owner ajanı belirler. Epic owner, Epic altındaki görevlerin ilerleme ve blokaj takibinden sorumludur.
-
-## Konsolidasyon
-
-1. **+operation-manager:** Tüm planning çıktılarını `../workspace/memory/backlog/` altında dashboard ve item dosyaları olarak oluşturur.
-	- Reviewer: +engineering-manager
-	- Approver: +prime
-> [!INFO] BACKLOG YAPISI
->```
-> ../workspace/memory/backlog/
->	├── version-dashboard.md
->	├── epic-dashboard.md
->	├── debt-dashboard.md
->	├── TXX-[task-name].md
->	├── BXX-[bug-name].md
->	└── DXX-[debt-name].md
->```
-
-## Bildirim
-
-> [!NOTE] PLANLAMA TAMAMLANDI
-> +prime, 
-> [project-name] planlaması tamamlandı. 
-> `../workspace/memory/backlog/` için `!approve/reject backlog` komutunu bekliyorum.
-> Onaydan sonra ortam kurulumu akışı için `!setup environment` komutunu bekleyeceğim.

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.