Ürün gereksinim belgesi (PRD)

Ne zaman

• "Şu özelliği yapalım", "üyelik sistemi ekleyelim, planla", "ne yapacağımızı netleştir" gibi istekler.
• Birden çok bölümü ilgilendiren ya da bir haftadan uzun sürecek bir iş panoya girmeden önce.
• Kullanılmaz: işlerin zamana yayılması (yol-haritasi), bu haftanın görev dağıtımı (haftalik-plan), devam eden projenin durumu (proje-durum-raporu), arayüz tasarımı (Lyra).

Girdi

• Kullanıcının isteği ve projesi: recall "<proje>" ile proje kartı, hedefler, önceki kararlar (decisions/), varsa Nova'nın pazar ve rakip notları (knowledge/pazar/).
• Kimin için, hangi sorunu çözüyor, ne zamana.
• Eksikse tek soruda sor: hangi kullanıcı, hangi sorun, başarıyı nasıl anlarız. Cevap gelene kadar outcome "blocked".

Adımlar

1. recall "PRD <özellik>" ile önceki belgeyi bul. Varsa yeni sürüm yaz; eskiyi silme, "Değişiklik" bölümüne ekle.
2. Problemi tek paragrafta yaz: kim, hangi durumda, neyi yapamıyor, bugün nasıl idare ediyor. Kanıt (kullanıcı sözü, İris'in destek notu, Nova'nın verisi) yoksa "varsayım" yaz.
3. Kullanıcıları yaz: birincil ve ikincil kullanıcı, her biri için tek cümlelik ihtiyaç.
4. Hedefler (en çok 3) ve hedef dışı olanlar (bu sürümde YAPILMAYACAKLAR). Hedef dışı listesi boş kalmaz.
5. Gereksinimleri yaz, öncelikle: "Olmazsa olmaz", "Olsa iyi", "Sonra". Her gereksinim tek cümle, test edilebilir.
6. Her olmazsa olmaz gereksinim için kabul kriteri: "Verildiğinde … yapıldığında … beklenir" biçiminde, ölçülebilir.
7. Ölçütler: başarı ölçütü (ör. kayıt tamamlama oranı), başlangıç değeri ve hedef. Bilinen değer yoksa "bilinmiyor; ölçüm ilk görev" yaz, sayı uydurma.
8. Riskler ve bağımlılıklar: teknik, hukuki (KVKK → Themis), maliyet (Plutus), tasarım (Lyra). Her risk için azaltma adımı.
9. Açık sorular: kararı kullanıcıya ait olanlar ayrı listede.
10. memory_write ile projects/<proje>/PRD-<özellik>.md yoluna yaz.
11. Görevlere böl: her parça için create_task (tek sahip, mevcut kadrodan; kabul kriteri PRD'den; açıklamada PRD yolu ve görev için yöntem gerekiyorsa Skill: <ad>, ör. tasarım için Skill: tasarim-belgesi). Bağımlı görevleri açıklamada belirt.
12. Kullanıcıya özet GÖNDERME (Aqu yazar); kullanıcı doğrudan sorduysa send_message ile kısa cevap ve belge yolunu yaz. Açık soru varsa tek mesajda sor.

Kontrol listesi

• Problem, kanıtıyla ya da "varsayım" işaretiyle yazılı.
• Hedef dışı listesi dolu.
• Her olmazsa olmaz gereksinimin ölçülebilir kabul kriteri var.
• Ölçütlerde uydurma sayı yok; bilinmeyen "bilinmiyor".
• Riskler sahibiyle ve azaltma adımıyla.
• Görevlerin her birinin tek sahibi ve kabul kriteri var; sahipler mevcut kadrodan.

Çıktı

# PRD: <özellik> (<proje>, YYYY-MM-DD, sürüm <n>)

## Problem
<kim, hangi durumda, neyi yapamıyor> · kanıt: <kaynak | varsayım>

## Kullanıcılar
- Birincil: <…> — ihtiyaç: <…>
- İkincil: <…>

## Hedefler
1. …
## Hedef dışı (bu sürümde yok)
- …

## Gereksinimler
| # | Gereksinim | Öncelik | Kabul kriteri |
|---|---|---|---|
| G1 | … | Olmazsa olmaz | Verildiğinde … yapıldığında … beklenir |

## Ölçütler
| Ölçüt | Başlangıç | Hedef | Nasıl ölçülür |
|---|---|---|---|

## Riskler ve bağımlılıklar
- <risk> · sahibi: <ajan> · azaltma: <…>

## Açık sorular (kullanıcı kararı)
- …

## Görevler
- <görev> · sahibi: <ajan> · bağlı: <G1>

## Değişiklik
- YYYY-MM-DD: …

Bitti sayılır

• PRD projects/<proje>/ altında; kontrol listesi tam.
• Görevler panoda tek sahipli ve kabul kriterli; açık sorular kullanıcıya iletildi.