این سند، نقشهٔ راه تجاری را به تحویلهای قابلردیابی برای معماری فعلی Rust + Tauri v2 + HTML/CSS/JavaScript تبدیل میکند. نسخهٔ فعلی یک vertical slice قابلبازی با بیش از ۱۴ اتاق، بیش از ۲۰ آیتم، شش معما، ۱۳ achievement، نقشهٔ پویا و سه اسلات ذخیره است. این ویژگیها پایهٔ خوبی هستند، اما جای اعتبارسنجی بازیکن، فرایند فروشگاهی، QA خارجی و عملیات محصول را نمیگیرند.
| جریان کاری | وضعیت نسخهٔ v2.0 | شکاف اصلی | اولویت |
|---|---|---|---|
| محصول | رابط cyberpunk، فرمانهای متنی، معما، نقشه و ذخیره موجود است | تجربهٔ شروع، مسیر پایان و کیفیت save/load باید با بازیکن واقعی آزمون شوند | P0 |
| کیفیت | موتور Rust، Tauri commandها و workflow انتشار ویندوز موجود است | CI کیفیت برای pull request و build بومی Linux/macOS لازم است | P0 |
| اعتبارسنجی بازار | هنوز هیچ دادهٔ واقعی از مخاطب، دمو یا willingness-to-pay ثبت نشده است | صفحهٔ فرود، مصاحبه، playtest و log انتساب لازم است | P0 |
| حریم خصوصی | برنامه آفلاین و محلی است | هر SDK/فرم/analytics آینده نیازمند inventory و بازبینی حقوقی است | P0 |
| توزیع | release ویندوز و pipeline tag-triggered وجود دارد | صفحهٔ itch.io/Steam، بستهٔ Linux/macOS، امضای کد و پشتیبانی عملیات باقی مانده | P1 |
| بومیسازی | رابط و محتوا انگلیسی هستند | قرارداد ترجمه، آزمون طول متن و RTL پیش از زبان دوم لازم است | P1 |
| بازه | هدف | تحویلهای عملیاتی | شرط ادامه |
|---|---|---|---|
| هفتههای ۱ تا ۲ | تعریف فرض محصول | سه پیام صفحهٔ فرود، فرم دمو، UTM، پروتکل ۱۲ مصاحبه | یک مالک و یک معیار تصمیم برای هر آزمایش ثبت شده باشد. |
| هفتههای ۳ تا ۶ | رفع موانع آغاز و save/load | پنج playtest بدون راهنما، تست مسیرها، گزارش reset/ذخیره، backlog MoSCoW | بازیکنان بتوانند هدف اولیه را بدون راهنما توضیح دهند. |
| ماههای ۲ تا ۳ | دمو کوچک و بازخورد خارجی | دمو قابلنصب، صفحهٔ itch.io، فرم بازخورد و log کانال | تصمیم ادامه/بازنویسی بر پایهٔ اتمام، بازخورد و ثبتنام واقعی باشد. |
| ماههای ۴ تا ۶ | آمادگی فروشگاه | صفحهٔ Steam «بهزودی»، press kit، دارایی تصویری و build چندسکویی آزمایشی | مشکل P0/P1 باز نمانده و پیام فروشگاه با بازخورد دمو همسو باشد. |
| ماههای ۷ تا ۹ | محتوای کامل و دسترسپذیری | مسیرهای داستانی کامل، QA خارجی، تنظیمات واقعی و بومیسازی آزمایشی | scope محصول قفل و مسیرهای اصلی قابلآزمون باشند. |
| ماههای ۱۰ تا ۱۲ | عرضه و عملیات | امضای کد، checklist فروشگاه، پشتیبانی، hotfix و dashboard ماهانه | عرضه کنترلشده و مرور KPI در هفتهٔ اول انجام شود. |
| شناسه | تحویل | تعریف اتمام |
|---|---|---|
| VAL-01 | صفحهٔ فرود سهپیامی | هر پیام URL/UTM، CTA، رضایت و روش ثبت بازخورد مستقل دارد. |
| VAL-02 | مصاحبه و playtest | دوازده مصاحبه و پنج playtest با گزارش مسیر، نقلقول و مانع انجام میشود. |
| QUA-01 | ماتریس مسیر/ذخیره | new game، load، save در هر سه اسلات، حذف save و پایانها test case دارند. |
| QUA-02 | قرارداد backend/frontend | هیچ دکمهٔ UI به دادهای که GameResponse آن را برنمیگرداند وابسته نیست؛ load نباید بازی را reset کند. |
| PRV-01 | inventory داده | وضعیت «بدون حساب و بدون telemetry» ثبت است؛ هر انتقال داده یا SDK آینده پیش از merge بررسی میشود. |
مهمترین اقدام بعدی: اول playtest و مسیر load/save را تثبیت کنید؛ پیش از تولید محتوای بیشتر یا تبلیغ پولی، موانع ۱۵ دقیقهٔ نخست باید برطرف شوند.
| شناسه | تحویل | تعریف اتمام |
|---|---|---|
| PLAT-01 | CI اعتبارسنجی چندسکویی | build/test بومی Tauri روی Windows، Linux و macOS در pull request اجرا شود. |
| PLAT-02 | بستههای آزمایشی | artifact بومی هر پلتفرم همراه با checksum تولید شود؛ انتشار عمومی به امضا و آزمون native موکول است. |
| MKT-01 | itch.io و press kit | دمو، توضیح کوتاه، اسکرینشات، اطلاعات تماس و فرم بازخورد فراهم است. |
| MKT-02 | صفحهٔ Steam | تگها، capsule art، تریلر، زبانها، قیمت و لینک حریم خصوصی بازبینی شدهاند. |
| LOC-01 | قرارداد بومیسازی | کلیدها، placeholder، طول متن، فونت و آزمون RTL مستند است؛ زبان دوم بر پایهٔ تقاضا انتخاب میشود. |
| OPS-01 | پشتیبانی و dashboard | کانال پشتیبانی، SLA داخلی، ثبت بازپرداخت/باگ و شیت KPI آماده است. |
مهمترین اقدام بعدی: یک workflow جداگانه برای quality و build بومی اضافه کنید؛ pipeline فعلی tag release را تا زمانی که امضا و دارایی فروشگاه آماده نیست، فقط برای ویندوز نگه دارید.
| تصمیم | دلیل وابستگی | خروجی مورد نیاز |
|---|---|---|
| نهاد و کشور دریافتکنندهٔ درآمد | مسیر مالیات، Steam Direct، بانک و قراردادها را تعیین میکند | مشاورهٔ حقوقی/مالیاتی محلی |
| بودجهٔ اعتبارسنجی | سقف نمونهسازی، دارایی، playtest و تبلیغ را تعیین میکند | budget ماهانه و runway |
| بازار اول و زبان دوم | هزینهٔ محلیسازی و پیام فروشگاه را تعیین میکند | تقاضای ثبتشده از دمو/فرم |
| کانال فروش اولیه | تکالیف حریم خصوصی، پشتیبانی و بازپرداخت را تغییر میدهد | تصمیم itch.io-only یا Steam |
| امضا و هویت تجاری | انتشار Windows/macOS و دارایی فروشگاه به آن وابسته است | بررسی نام/علامت و گواهی مناسب |
هر چرخهٔ دو هفتهای باید با یک فرض قابلرد شروع و با تصمیم مکتوب خاتمه یابد: داده چه گفت، چه چیزی متوقف میشود و کار بعدی چیست. دادهٔ واقعیِ مخاطب بر ویژگیهایی که صرفاً «جذاب به نظر میرسند» اولویت دارد.
مهمترین اقدام بعدی: برای هر تحویل P0 یک مالک مشخص کنید و هفتهای یکبار فقط موانع، شواهد و تصمیمهای هفتهٔ بعد را مرور کنید.