Plan Configurator و Structured Lead Intent

1) مسئله‌ای که این درس حل می‌کند

اگر configurator فقط کارت، label و یک total نمایشی ذخیره کند، بعداً نمی‌توان با اطمینان گفت کاربر دقیقاً چه plan، price، quantity و optionهایی را انتخاب کرده یا چرا آن ترکیب معتبر بوده است.

2) مرز درس

خروجی این درس Plan Configurator Intent Contract v1 است. این درس مالک Information Architecture درس قبل یا CRM Handoff درس بعد نیست و هیچ checkout، billing یا mutation واقعی انجام نمی‌دهد.

3) Fact: Product و Price یک چیز نیستند

Stripe محصول و قیمت را جدا مدل می‌کند. Product می‌گوید چه چیزی فروخته می‌شود و Price شرایط مبلغ/واحد/دوره را نگه می‌دارد. پس product_id و price_id را نباید با نام نمایشی plan جایگزین کرد.

4) Fact: pricing model و lifecycle قیمت باید قابل ردیابی باشد

Stripe مدل‌های flat-rate، per-seat و usage-based را مستند می‌کند. برای تغییر مبلغ، راهنمای فعلی Stripe ساخت Price جدید و archive کردن Price قبلی را برای حفظ سابقه توصیه می‌کند. بنابراین total ذخیره‌شده بدون price_id و price_version evidence کافی نیست.

5) Fact: کنترل‌های form-like باید label و feedback قابل شناسایی داشته باشند

W3C برای inputها label/instruction و برای interaction feedback قابل تشخیص می‌خواهد. این الزام به خود UI مربوط است؛ eligibility، dependency یا قیمت را تعریف نمی‌کند.

6) Inference: submission باید بدون اعتماد به UI قابل بازسازی باشد

اگر فقط متن «Pro Annual — 490» ذخیره شده باشد، بعد از rename یا تغییر price معلوم نیست کدام قرارداد واقعی حاکم بوده است. auditable بودن یعنی از identifier و version و state بتوان تصمیم را دوباره ساخت.

7) Design: هویت session و selection را حفظ کن

config_session_id باید submission را به plan، price، quantity و optionهای همان لحظه متصل کند. labelهای انسانی کمک‌کننده‌اند، اما کلید پایدار نیستند.

8) Price identity را از estimated total جدا کن

estimated_price یک نتیجه است؛ price_id، pricing_model، billing_period و price_version ورودی‌های قراردادی‌اند. cached total نباید بتواند version mismatch را پنهان کند.

9) Dependency و incompatibility را صریح ارزیابی کن

مثلاً add-on جدید فقط برای annual plan مجاز است. اگر monthly انتخاب شده، state باید INVALID_DEPENDENCY باشد؛ UI نباید صرفاً option را مخفی کند و evidence را حذف کند.

10) Quantity و pricing model semantics را حفظ کن

عدد 25 ممکن است seat count باشد یا usage quantity. quantity_dimension مشخص می‌کند quantity چه معنایی دارد. بدون آن، بازسازی قیمت و intent قابل اعتماد نیست.

11) Eligibility و quote-required را با acceptance یکی نکن

Enterprise می‌تواند QUOTE_REQUIRED باشد و eligibility ممکن است UNKNOWN بماند. نبود evidence نباید به eligible یا invalid تبدیل شود؛ state محدودکننده را حفظ کن.

12) Core Evidence Contract

این قرارداد 22 بُعد دارد که 16 بُعد آن critical است. جدول زیر baseline، invalid dependency و historical reconstruction را خلاصه می‌کند؛ فایل JSON/CSV mapping کامل را نگه می‌دارد.

13) Structured Lead Intent را از selection بساز

intent_payload باید از plan، quantity، option، constraint result و validation state ساخته شود. intent را از headline، card title یا total نمایشی reverse-engineer نکن.

14) Typed state از false certainty جلوگیری می‌کند

ACCEPT فقط برای evidence کافی است. QUOTE_REQUIRED، HOLD_ELIGIBILITY_UNKNOWN، HOLD_PRICE_STALE، HOLD_PRICE_VERSION_MISMATCH، INVALID_DEPENDENCY و BLOCKED_EVIDENCE_MISSING همگی stateهای معتبرند.

15) Lab و Transfer

Lab هشت fixture و 48 assertion دارد. در transfer یک usage-based add-on اضافه می‌شود، price قدیمی archive می‌شود و option خاص فقط annual می‌شود. submission جدید باید از price قدیمی متوقف شود، اما lead تاریخی فقط وقتی قابل بازسازی است که identifier، زمان submission و version evidence دقیق داشته باشد.