kortext 3.0.0 → 3.1.0

package/rules/models.md

@@ -1,93 +0,0 @@
-# Model Konfigürasyonu
-
-Bu dosya, personanın görev türüne göre hangi model profilini kullanacağını merkezi olarak tanımlar. Persona dosyalarında doğrudan model adı yazılmaz; persona dosyaları yalnızca görev kategorisini belirtir.
-
-## Görev Kategorileri
-
-| Kategori | Kullanım Alanı | Varsayılan Profil | Fallback Profil |
-| :--- | :--- | :--- | :--- |
-| `deep-research` | Araştırma, analiz, mimari tasarım, strateji, karmaşık kod üretimi, güvenlik değerlendirmesi | `high-reasoning` | `standard-reasoning` |
-| `routine` | Format düzenleme, standart güncelleme, raporlama, basit denetim, düşük riskli rutin işler | `fast-reasoning` | `standard-reasoning` |
-
-## Model Profilleri
-
-| Profil | Beklenen Özellik | Kullanım |
-| :--- | :--- | :--- |
-| `high-reasoning` | En güçlü muhakeme, uzun bağlam, karmaşık analiz | Kritik teknik kararlar ve çok adımlı üretim işleri |
-| `standard-reasoning` | Dengeli muhakeme ve hız | Fallback veya orta karmaşıklıktaki işler |
-| `fast-reasoning` | Hızlı cevap, düşük maliyet | Rutin raporlama ve basit kontrol işleri |
-
-## Rol → Kategori Ataması
-
-| Persona | Varsayılan Kategori | Not |
-| :--- | :--- | :--- |
-| `+operation-manager` | `routine` | Orkestrasyon, durum takibi, raporlama |
-| `+product-manager` | `deep-research` | Ürün gereksinimi, kapsam ve önceliklendirme |
-| `+engineering-manager` | `deep-research` | Mimari, teknik karar, code review |
-| `+delivery-manager` | `routine` | Release koordinasyonu ve teslimat raporları |
-| `+backend-developer` | `deep-research` | Backend uygulama ve servis mantığı |
-| `+frontend-developer` | `deep-research` | UI uygulama ve frontend mimarisi |
-| `+db-admin` | `deep-research` | Veri modeli, migration, performans |
-| `+devops-engineer` | `routine` | CI/CD, ortam, deployment operasyonları |
-| `+qa-engineer` | `routine` | Test yürütme, doğrulama, raporlama |
-| `+security-engineer` | `deep-research` | Güvenlik analizi, risk ve zafiyet değerlendirmesi |
-| `+designer` | `deep-research` | Tasarım sistemi, UX/UI değerlendirmesi |
-| `+copywriter` | `deep-research` | İçerik stratejisi, marka dili, mikro metin |
-| `+growth-expert` | `deep-research` | SEO/GEO, analitik, büyüme stratejisi |
-| `+compliance-expert` | `deep-research` | KVKK/GDPR ve yasal değerlendirme |
-
-## Sağlayıcı Seçimi
-
-Gerçek model ID'leri sağlayıcıya ve kurulu ortama göre değişebilir. Bu nedenle model ID'leri persona dosyalarına yazılmaz.
-
-## Resmi Model Kaynakları
-
-Model seçimi veya model güncellemesi yapılmadan önce sağlayıcının resmi model dokümantasyonu kontrol edilir.
-
-| Sağlayıcı | Resmi Kaynak |
-| :--- | :--- |
-| Anthropic / Claude | https://docs.anthropic.com/en/docs/about-claude/models/overview |
-| Google / Gemini | https://ai.google.dev/gemini-api/docs/models |
-| OpenAI | https://developers.openai.com/api/docs/models |
-
-## Güncellik Kuralı
-
-- +prime "en güncel", "latest" veya belirli bir sağlayıcıdaki yeni model ailesini isterse ajan resmi model dokümanını kontrol etmeden model önermemelidir.
-- Varsayılan tercih +prime aksi yönde belirtmedikçe en güncel uygun modeldir.
-- Production kullanımında model ID sabitlenmesi gerekiyorsa ilgili snapshot/stable ID `workspace/references/access.md` veya `workspace/references/tech-stack.md` içinde ayrıca belgelenir.
-- Bir sağlayıcının "latest" alias'ı ile sabit snapshot ID'si farklı amaçlara hizmet ediyorsa bu fark raporda açıkça belirtilir.
-
-Model seçimi yapılırken:
-
-1. Önce görevin kategorisi belirlenir.
-2. Resmi model kaynağı kontrol edilir.
-3. Kategoriye karşılık gelen varsayılan profil seçilir.
-4. Mevcut ortamda bu profile karşılık gelen en güncel uygun model kullanılır.
-5. Model erişilemezse fallback profil kullanılır.
-6. Fallback kullanımı `workspace/reports/status-reports.md` veya ilgili görev raporuna not edilir.
-
-## Fallback Politikası
-
-- Fallback modeli aynı görevi tamamlamak için yeterliyse işlem devam eder.
-- Fallback kalite riski oluşturuyorsa görev `Blocked` yapılır ve +operation-manager'a eskale edilir.
-- `deep-research` görevlerinde fallback kullanıldıysa sonuç kalitesi özellikle belirtilir.
-- API/LLM kesintilerinde retry ve fallback sırası `rules/emergency.md` içindeki Self-Healing Protocol'e göre yürütülür.
-
-## Persona Dosyalarında Kullanım
-
-Persona dosyalarının `instructions` bölümünde her görev adımında model adı yerine kategori referansı kullanılır:
-
-```markdown
-### 1. Araştırma Protokolü
-**Kategori:** `deep-research`
-
-### 2. Rutin Güncelleme
-**Kategori:** `routine`
-```
-
-## Güncelleme Politikası
-
-- Model profili veya kategori değişikliklerinde yalnızca bu dosya güncellenir.
-- Gerçek sağlayıcı/model ID eşleşmeleri proje ortamına göre `workspace/references/tech-stack.md` veya `workspace/references/access.md` içinde belgelenir.
-- Model değişikliği önerisi +operation-manager tarafından yapılır.
-- Stratejik model değişikliği +prime onayı gerektirir.

package/scripts/copy-migrations.mjs

@@ -1,29 +0,0 @@
-#!/usr/bin/env node
-// Post-build step: tsc doesn't copy non-TS assets. The migration runner
-// expects `server/db/migrations/*.sql` next to the compiled `migrate.js`,
-// so we mirror them into `dist/server/db/migrations/` after tsc emits.
-
-import { cpSync, mkdirSync, readdirSync, existsSync } from 'node:fs';
-import { dirname, join, resolve } from 'node:path';
-import { fileURLToPath } from 'node:url';
-
-const here = dirname(fileURLToPath(import.meta.url));
-const root = resolve(here, '..');
-const src = join(root, 'server', 'db', 'migrations');
-const dst = join(root, 'dist', 'server', 'db', 'migrations');
-
-if (!existsSync(src)) {
-  console.error(`[copy-migrations] source missing: ${src}`);
-  process.exit(1);
-}
-if (!existsSync(join(root, 'dist'))) {
-  console.error('[copy-migrations] dist/ not found — did `tsc` run?');
-  process.exit(1);
-}
-
-mkdirSync(dst, { recursive: true });
-const files = readdirSync(src).filter((f) => f.endsWith('.sql'));
-for (const f of files) {
-  cpSync(join(src, f), join(dst, f));
-}
-console.error(`[copy-migrations] copied ${files.length} migration file(s) → ${dst}`);

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.