# MVP VNOS — سند مادر دامنه (v0.2.0)

**وضعیت:** Proposed for validation / تصمیم‌سازی؛ نه تأیید نهایی قرارداد یا آماده بهره‌برداری.  
**بازنگری:** 2026-10-25  
**مالک محصول:** VNOS Product; ذی‌نفع پایلوت: آرد ورامین، سمیرا، افق کوروش.  
**اصل برتر:** [Architecture Constitution](../architecture-principles.md)؛ هر قابلیت باید Headless, API-First, Metadata-Driven, Configurable, Modular, Source-Agnostic باشد.

## 1. فرضیه‌ای که MVP باید اثبات کند
VNOS می‌تواند بدون کدنویسی اختصاصی برای سه نام تجاری، یک شبکه ارزش بین‌سازمانی را تعریف، اجرا و ممیزی کند: **تقاضا/تأمین → تبدیل مواد → تحویل → فروش/مرجوعی → تعهد مالی/تسویه**. تمام داده‌ها و قوانین به شرکت، قرارداد، سازمان، نقش، دوره و نسخه وابسته‌اند، نه به if/else در Core.

### خروجی ملموس پایلوت
یک پرونده زنجیره‌ای قابل ردیابی از محموله/بچ گندم تا یک یا چند بچ آرد و ماکارونی و رخداد فروش فروشگاهی، همراه با شواهد، گردش تأیید، مغایرت‌ها و مانده مطالبات؛ تمام اینها با API قابل اجرا باشد. اگر POS فقط SKU دهد، انتساب به بچ «تخمینی» است.

## 2. بازیگران و حدود مسئولیت
| بازیگر | نقش پایلوت | کارهایی که باید بتواند انجام دهد |
|---|---|---|
| مدیر کل پلتفرم | اداره Control Plane | سازمان، نقش، مدل، فرم، قواعد، workflow، اتصال، نسخه، سیاست و audit |
| مدیر شبکه/اپراتور | نظارت بین‌سازمانی | دعوت طرف‌ها، عقد/فعال‌سازی روابط، رسیدگی به اختلاف، مشاهده وضعیت شبکه طبق مجوز |
| ورامین | تأمین/آسیاب | ثبت گندم، اسناد و کیفیت، تخصیص، تولید آرد، حواله و مطالبه |
| سمیرا | تولیدکننده | درخواست آرد، برنامه تولید، مصرف واقعی، batch محصول، ارسال و طلب |
| افق کوروش | خریدار/خرده‌فروش | درخواست/سفارش، تأیید رسید، موجودی، فروش POS، برگشت و تأیید دوره |
| کارشناس مالی هر شرکت | مالی | مشاهده بدهکار/بستانکار مجاز، رد/تأیید محاسبه، مدارک پرداخت/تطبیق |
| ممیز | نظارت | خواندن رویدادها، اسناد، نسبت منشأ، اقدامات و تاریخچه با دسترسی تعریف‌شده |
| سیستم/یکپارچه‌ساز | ورود داده | API و فایل با شناسه منبع، نگاشت فیلد و کلید idempotency |

شرکت‌های بالا رکوردهای پیکربندی نمونه هستند؛ نباید نام آنها در schema/domain code ثابت شود.

## 3. محدوده در MVP
### MUST — برش پایلوت قابل پذیرش
- تعریف سازمان، کاربر، نقش، عضویت چندسازمانی، محدوده داده و امکان تعلیق.
- تعریف metadata برای مدل‌های قابل توسعه؛ انتشار نسخه مدل، field/relationship validation، ایجاد داده از API و فرم تولیدشده از metadata؛ تغییرات SQL فقط با Schema Engine کنترل‌شده.
- تعریف طرف قرارداد و رابطه تجاری و workflowهای قابل تنظیم با وضعیت/تصمیم/کارشناس مسئول.
- ثبت lot گندم، دریافت/موجودی/اسناد/کیفیت/وضعیت اعتماد، اختلاط و تولید آرد با مصرف واقعی و mass balance.
- تقاضا/سفارش، برنامه تولید و درخواست/تأیید آرد، رزرو موجودی بدون over-allocation.
- تولید ماکارونی با BOM نسخه‌دار، input lot و output batch، QC و ضایعات.
- حواله/حمل/تحویل جزئی، تأیید گیرنده، اختلاف وزن/کیفیت/تعداد و پرونده رسیدگی.
- دریافت فروش و مرجوعی در حد داده واقعی (فایل یا API)، حذف تکراری، reconciliation و confidence ردیابی.
- قرارداد و موتور قواعد مالی نسخه‌دار، سند دوبل تعهد، مانده، تأیید دوره، برگشت/اصلاح و ثبت مدرک پرداخت برون‌سامانه.
- audit سراسری، provenance، اعتبارسنجی API، رویدادهای outbox، گزارش رهگیری و مانده دوره.
- یک رابط فارسی RTL برای عملیات پایلوت و یک Control Plane حداقلی؛ API مستقل از رابط کاربری.

### SHOULD — در صورت آمادگی داده و بودجه
- اتصال واقعی ERP/WMS/POS با source mapping نسخه‌دار، جایگزین یا مکمل ورود دستی.
- اعلان داخلی/ایمیل، تأیید چندمرحله‌ای، داشبورد مغایرت‌ها و KPI کیفیت داده.
- traceability در سطح فروشگاه و رابطه موجودی فروشگاه با batch در صورت وجود شواهد.
- نمایش QR/شناسه دیجیتال بچ؛ ثبت اختیاری hash شواهد در دفترکل بیرونی پس از PoC.

### خارج از تعهد MVP
انتقال وجه واقعی توسط VNOS؛ صدور بیمه‌نامه و پرداخت خسارت؛ عرضه اوراق/تأمین مالی عمومی؛ توکن قابل معامله یا سند مالکیت خودکار؛ اثبات batch یک بسته صرفاً از GTIN؛ اتصال تضمینی به همه دستگاه‌ها و سازمان‌های دولتی؛ راه‌اندازی تمام صنایع؛ الگوریتم‌های پیچیده AI پیش‌بینی تقاضا.

## 4. هسته پلتفرم در مقابل پیکربندی صنعت
| Platform Core | Configured industry instance |
|---|---|
| Entity, Field, Relation, Rules, Workflow, Tenant, Identity, Audit | مدل Lot گندم/آرد/ماکارونی و مشخصات کیفی |
| Source Integration & Mapping | CSV اولیه ورامین، خروجی POS افق، ERP سمیرا |
| Inventory & Transformation primitives | دستور آسیاب و نسبت مواد مصرفی |
| Contract / Ledger / Settlement engine | درصدها، تاریخ مبنا، دوره تسویه و طرف بدهکار |
| API / Event / Schema runtime | فرم‌های فارسی پایلوت، برچسب‌ها، نقش‌ها و مراحل |

**ممنوع:** اختصاص نام شرکت به endpoint، Entity subclass غیرقابل تعمیم، قیمت/سهم ثابت، workflow گره‌خورده به صفحه، DDL دلخواه از UI، bypass مجوز در import.

## 5. User journeys / flows
- [نقش‌ها و سفرهای کاربر](personas-and-journeys.md)
- [۱۲ جریان قدم‌به‌قدم و مسیرهای خطا](user-flows.md)
- [وضعیت‌ها، رخدادها، قوانین و پذیرش](states-and-acceptance.md)
- [تصمیم‌ها و مسائل باز](open-decisions.md)
- [صفحه قابل مرور MVP](../../mvp.html)

## 6. معیار موفقیت و گیت خروج
این‌ها **اهداف پیشنهادی برای مصوب‌سازی** هستند، نه KPI قطعی قراردادی:
1. یک پرونده از منبع گندم تا گزارش فروش/تسویه با رابطه قابل مشاهده و شواهد تکمیل شود.
2. هیچ stock reservation منفی یا journal نامتوازن در تست رقابت همزمان رخ ندهد.
3. هر مرحله با API بدون UI انجام و بازپخش منبع تکراری بدون ثبت مضاعف آزمایش شود.
4. افزودن یک فیلد پشتیبانی‌شده یا تغییر قاعده/فرم بدون patch به Core انجام و در UI و API قابل رؤیت باشد.
5. تغییر سازمان/نقش، دسترسی غیرمجاز را در تمام APIها و گزارش‌ها مسدود کند.
6. تصحیح اسناد مالی و رویدادهای زنجیره‌ای با سابقه ثبت شود، نه حذف یا بازنویسی بی‌ردپا.
7. داده فروش بدون batch با برچسب «سطح SKU / تخصیص استنباطی» نمایش داده شود.
8. ذی‌نفعان هر سه شرکت و مالک محصول UAT را با سناریوهای انتهابه‌انتها امضا کنند.

## 7. طراحی توسعه برشی
S0 Foundation → S1 Metadata-to-API thin slice → S2 Organization/Contract/Workflow → S3 Lot/Inventory → S4 Order/Allocation → S5 Production/Transformation → S6 Fulfillment/QC → S7 Retail feed → S8 Ledger/Reconciliation → S9 UAT/Hardening.  
هیچ اسلایسی بدون API contract، تست، مستندات، UI در صورت لزوم، audit و سناریوی خطا Done نیست.

## 8. وضعیت تأیید
این متن، مبنای تحلیل و طراحی است. محرک اصلی خرید، مالکیت‌ها، مبنای تسویه، قیمت‌گذاری، پذیرش اسناد، tolerance، روش تأمین و سایر موارد [در لیست تصمیم باز](open-decisions.md) نیازمند امضا هستند. از داده آزمایشی برای دور زدن تصمیم حقوقی یا مالی استفاده نکنید.