mini-prd

name: mini-prd description: Yeni bir feature için hafif PRD üretir (tam spec-first-feature pipeline'ı değil). docs/SYSTEM.md + hedefli grep ile harmony'yi garanti eder, Entegrasyon bölümünü zorunlu kılar ve docs/prd-.progress.md ile aktif PRD işaretini kurar. prd-run bittikten sonra test-plan → qa-eval-developer → project-manager (AUTO-GO) → git push → live-test pipeline'ını otomatik tetikler. Tetikleyiciler: prd-guard uyarısı sonrası, "kısa PRD yaz", "mini PRD", "bu küçük feature için spec".

Yeni feature küçükse tam pipeline yerine hafif ama harmony-garantili bir PRD üret.

Uzman-Ajan-Önce Soru Protokolü (LAW — operatöre sormadan önce uzman ajan KARAR VERİR)

Mini-PRD içinde çıkan HER karar/açıklama sorusu önce uzman subagent'a gider; karar onların. Kritik teknik kararlar (auth, compliance, teknoloji seçimi, veri modeli, irreversible mimari) dahil ajan karar verir — operatöre sormaz. Operatöre yalnızca ajan cevap veremediğinde (ürün niyeti / iş kararı / "ne istiyorsun" / kullanıcı-yüzlü isim) soru sorulur.

Soru tipi	Karar veren
Mimari, tasarım, teknoloji/library seçimi, veri modeli, API şekli, auth, compliance, güvenlik pattern'i	`software-architect` ajanı
Deploy, infra, CI/CD, runtime, observability, secrets, DEPLOY.md	`devops-engineer` ajanı (devops-expert skill bilgisini kullanır)
Ürün niyeti / iş kapsamı / "ne istiyorsun" / kullanıcı-yüzlü isim / fiyat politikası	(ajan cevaplayamaz → operatör)

Akış: soruyu sınıflandır → teknikse uzman ajan(lar)ı dispatch et (self-contained prompt: SYSTEM.md yolu + repo kökü + soru + kısıtlar; "araştır + ≥2 kanıt + karar + güven" iste; ajan ürün girdisi gerekiyorsa CANNOT-ANSWER döner) → ajan karar verdiyse benimse, kaynağıyla §5 Entegrasyon / karar notuna yaz → ajan CANNOT-ANSWER derse veya ajanlar çelişirse operatöre (ajan analizini ekleyerek) git.

Kapsam: Bu protokol PRD yazımı içindeki kararları kapsar; §6 (remote git) ve §7 (AWS public/silme) çalıştırma-zamanı LAW'ları etkilenmez — onlar uygulama anında hâlâ operatör onayı ister.

Hard Sequence (atlanmaz)

SYSTEM.md kontrol — docs/SYSTEM.md var mı?
- Varsa oku.
- Yoksa: feature'ın dokunduğu alanlar için bir kez üret (spec-first-feature Phase 1 mantığı, dar kapsam) → docs/SYSTEM.md.
Hedefli grep — feature'ın dokunduğu modülleri (auth + ilgili servis/tablo) grep'le; dosya:satır kanıtı topla. Tam tarama YAPMA.
Şablonu doldur — templates/mini-prd.md'yi kopyala → docs/prd-<feature>.md. §5 Entegrasyon'u Adım 2 kanıtıyla doldur (boş alan = fail).
AC binary mı kontrol et — her AC geçti/kaldı net olmalı (L107).

Progress dosyası oluştur — docs/prd-<feature>.progress.md yaz:

---
status: active
prd: docs/prd-<feature>.md
started: <YYYY-MM-DD>
---

## Faz Çıktıları

## Değişiklikler
| Tarih | Dosya | Ne değişti | AC |
|-------|-------|-----------|-----|

## Kararlar

## Dersler

prd-run bu dosyaya tüm faz çıktılarını, değişiklik takibini ve kararları yazar.

Çıktı

docs/prd-<feature>.md (mini-PRD, harmony dolu)
docs/prd-<feature>.progress.md (aktif PRD işareti + faz/değişiklik takibi için hazır)
Operatöre: 1 cümle özet + "prd-run ile uygulayalım mı?"

prd-run Sonrası Pipeline (ZORUNLU — implementasyon bittikten sonra)

prd-run tüm fazları tamamladığında aşağıdaki pipeline otomatik devreye girer. Operatör onayı gerekmez — tek kullanıcı aksiyonu git push komutudur (Golden Rule §6).

prd-run bitti
  1. /test-plan <feature>        → docs/test-plan-<feature>.md
  2. qa-eval-developer           → testleri yaz + koş → TEST GATE: PASS/FAIL
        ↓ PASS
  3. project-manager             → P1-P8 kontrol → AUTO-GO
        ↓ AUTO-GO
  4. Kullanıcı: git push origin <dal>
        ↓ push sonrası
  5. CI → deploy → <proje>-live-test (varsa)

TEST GATE FAIL veya NO-GO durumunda blokör ilgili agent'a handoff edilir, fix sonrası pipeline kaldığı yerden devam eder.

Progress dosyasına (docs/prd-<feature>.progress.md) pipeline tamamlanınca status: delivered eklenir.

Kapsam dışı

Büyük/çok-fazlı feature → spec-first-feature kullan. Mini-PRD tek-fazlık işler için.