PRD چیست و چرا برای Ralph حیاتی است؟

اگر در محیط شرکتی کار کرده باشی، حتماً به Product Requirement Document یا همان PRD برخورده‌ای. این سند یک چیز فوق‌العاده ارزشمند را اجبار می‌کند: قبل از اینکه چیزی را بسازی، باید بفهمی داری «چه» می‌سازی. برای حلقه Ralph این سند از نان شب واجب‌تر است — چون در هر Iteration، کل PRD در پایه Context Window مدل بارگذاری می‌شود. PRD همان «تصویر بزرگ» است با همه تصمیم‌های مهم که از قبل گرفته شده‌اند.

تعریف

PRD توصیف مکتوبِ مسئله، هدف، محدودیت‌ها و — مهم‌تر از همه — معیار موفقیت است. به سه سؤال بنیادی جواب می‌دهد: چه می‌سازیم؟ چرا می‌سازیم؟ و کِی می‌توانیم بگوییم «تمام شد»؟

آدم‌ها ابهام را با گفتگو حل می‌کنند — یا با دوازده جلسه، سه Follow-up و یک Thread اسلک که هرگز نمی‌میرد. ایجنت در جلسه شرکت نمی‌کند؛ ایجنت فقط آنچه نوشته شده را اجرا می‌کند. پس PRDِ آماده ایجنت باید ابهام را روی کاغذ بکشد.

نمونه واقعی: بازطراحی Onboarding در Production

سازنده سری با همین روش یک فیچر واقعی را به Production برد. مسئله: فرم ثبت‌نام کسب‌وکار یک فرم غول‌پیکر تک‌صفحه‌ای بود، بعد از ثبت‌نام فقط دو محصول پیش‌فرض داشتی و رابط همیشه هلندی بود — حتی اگر فرانسوی می‌خواستی. نتیجه بعد از Ralph: یک Wizard دو مرحله‌ای با انتخاب زبان، انتخاب دسته کسب‌وکار (اغذیه‌فروشی، نانوایی، ساندویچی و…)، و منوی از قبل پرشده با ۲۳ محصولِ متناسب با همان دسته. حتی ایمیل‌های `example.com` هم رد می‌شوند تا اکانت تستی تنبل‌ها ساخته نشود.

ساختار همان PRD واقعی:

اسکلت Markdown همان سند — این فرمت را بعداً Skill PRD هم تقلید می‌کند:

# PRD: Modernize business onboarding

## Problem
The signup form is one giant page. After signup the menu has
only two generic products. The UI is always Dutch.

## Goals
- Two-step wizard with language picker
- Capture business category (fry shop, bakery, sandwich, …)
- Seed a category-aware menu (23 products for a fry shop)
- Reject example.com emails (too many lazy test accounts)

## Out of scope
- Email verification
- Social login

## Technical approach
- New column `category` — append at end of table, never `->after()`
- Preset classes per category (see pseudocode below)
- Reuse existing UI components; do not invent a new dropdown

## Implementation tasks
- [ ] Migration: add nullable `category` at end of table
- [ ] Enum of business categories
- [ ] Registration controller + two-step wizard
- [ ] Category presets (FryShopPreset::applyTo)
- [ ] Reject `@example.com` on signup

جزئیات فنی که فقط مهندس می‌داند

اینجا جایی است که ما مهندس‌ها می‌درخشیم. یک نمونه از همان سند: ستون جدید `category` باید «در انتهای جدول» اضافه شود، چون LLM عاشق این است که بنویسد:

// ❌ چیزی که مدل دوست دارد بنویسد:
$table->string('category')->nullable()->after('title');
// روی MySQL یعنی بازسازی کامل جدول = قفل شدن جدول = Downtime در Production

// ✅ چیزی که PRD تحمیل می‌کند:
$table->string('category')->nullable(); // append at the end

یا با Pseudocode مشخص می‌کنیم کلاس‌های Preset چطور صدا زده شوند تا مدل چرخ را دوباره اختراع نکند:

if ($business->category === BusinessCategory::FryShop) {
    FryShopPreset::applyTo($business);
}

و صریح می‌نویسیم: «از کامپوننت‌های موجود استفاده کن» — وگرنه Ralph می‌رود برای خودش Dropdown جدید اختراع می‌کند.

Implementation Tasks: موتور حلقه

مهم‌ترین بخش سند، فهرست وظایف است. کل PRD در هر دور به مدل داده می‌شود؛ مدل اولین وظیفه باز را برمی‌دارد — «Migration ستون category را بساز» — انجام می‌دهد، تیک می‌زند و خارج می‌شود. دور بعد: «Enum دسته‌ها»، بعد «Controller ثبت‌نام»، و همین‌طور تا آخر.

به زبان ساده

PRD قبل از ساختن می‌گوید چه می‌سازیم، چرا، و کی تمام است. برای ایجنت باید نرده هم داشته باشد: نمونه کد، اسکیما، چیزهایی که نباید ساخته شوند.

مثال واقعی

فرم ثبت‌نام یک‌صفحه‌ای شد Wizard دو مرحله‌ای با انتخاب زبان و دسته کسب‌وکار؛ منوی پیش‌فرض از ۲ محصول بی‌ربط به ۲۳ محصول متناسب با «اغذیه‌فروشی» رسید. ستون category را عمداً آخر جدول گذاشتند تا MySQL در Production قفل نشود.