State Machines: States, Guards, Holds و Terminal States

این درس فقط یک پرسش محدود را مالک است: چطور یک workflow را طوری مدل کنیم که transitionهای مجاز، مسدود، قابل‌ازسرگیری و terminal صریح باشند، تغییر حالت ناممکن رد شود و دلیل هر تصمیم به‌صورت قابل بازرسی باقی بماند؟ artifact شواهدی درس Bounded State Machine Decision Record v1 است. این artifact فقط مرز workflow همین fixture را اثبات می‌کند؛ نه اینکه هر workflow الزاماً به State Machine نیاز دارد و نه اینکه یک diagram به‌تنهایی runtime enforcement را ثابت می‌کند.

1. Workflow محدود درس

fixture محلی یک review request با پنج state دارد: DRAFT، SUBMITTED، ON_HOLD، APPROVED و REJECTED. ماشین فقط زمانی trigger را می‌پذیرد که current state، edge تعریف‌شده و guard همگی transition را مجاز بدانند.

2. خطر booleanهای پراکنده

اگر workflow با flagهای مستقلی مثل submitted=true، approved=true و waiting=true نمایش داده شود، ترکیب‌هایی ممکن است شکل بگیرند که domain هرگز قصد آن‌ها را نداشته است. State Machine محدود، این ترکیب کنترل‌نشده را با یک state نام‌گذاری‌شده و مجموعه‌ای صریح از edgeهای مجاز جایگزین می‌کند.

3. هویت State

state باید یک وضعیت تصمیم‌ساز در domain محدود را نشان دهد. در این درس ON_HOLD صرفاً یک برچسب روی SUBMITTED نیست؛ یعنی کار فعلاً نمی‌تواند جلو برود و باید یک resume condition مشخص داشته باشد. نام state فقط وقتی ارزش دارد که معنای آن قابل توضیح و بازرسی باشد.

4. Transition با assignment ساده فرق دارد

نوشتن مستقیم state = APPROVED قرارداد workflow را دور می‌زند. هر transition باید current state، trigger، guard، next state و نتیجه‌ی evidence داشته باشد. fixture همه‌ی تغییرها را از یک transition boundary عبور می‌دهد تا edge غیرمجاز به‌صورت آشکار fail شود.

5. Guard

guard یک precondition صریح برای edge معتبر است. transition از SUBMITTED به APPROVED فقط وقتی مجاز است که approver_authorized=true باشد. مخفی‌کردن دکمه Approve در UI معادل enforce شدن guard در boundary نیست.

6. رد شدن Guard خودش Evidence است

اگر guard تأیید false باشد، ماشین state را به زور جلو نمی‌برد. transition رد می‌شود و state بدون تغییر می‌ماند. probe با نام guard_bypass_attempt این مشاهده را GUARD_REJECTED طبقه‌بندی می‌کند.

7. Hold باید قابل Resume باشد

ON_HOLD یک state غیرterminal است. این state نشان می‌دهد request فعلاً قابل پیشروی نیست و باید resume rule داشته باشد. در مسیر baseline، request به‌دلیل نیاز به اطلاعات بیشتر وارد ON_HOLD می‌شود و فقط با resume_ready=true به SUBMITTED برمی‌گردد.

8. Hold با Terminal یکی نیست

اگر ON_HOLD اشتباهاً terminal اعلام شود، resume path معتبر از بین می‌رود. probe با نام hold_marked_terminal_mutation این خرابی را با classification RESUME_PATH_BLOCKED_BY_FALSE_TERMINAL نشان می‌دهد. wait state باید شرط بازگشت داشته باشد، نه اینکه ناخواسته dead end شود.

9. Terminal State

APPROVED و REJECTED پایان عمدی همین review workflow هستند. در مرز این ماشین هیچ business transition خروجی ندارند. terminal بودن به این معنی نیست که کل سیستم متوقف می‌شود؛ فقط یعنی در workflow مدل‌شده edge بعدی وجود ندارد.

10. Mutation روی Terminal

probe با نام terminal_outgoing_transition_mutation یک edge مصنوعی APPROVED -> DRAFT اضافه می‌کند. contract check گراف دستکاری‌شده را با TERMINAL_CONTRACT_VIOLATION رد می‌کند. این negative evidence نشان می‌دهد terminal بودن فقط یک label روی diagram نیست.

11. Illegal Transition

تلاش برای APPROVED -> DRAFT به‌صورت silent normalize نمی‌شود. این تلاش با ILLEGAL_TRANSITION_REJECTED رد می‌شود و state همچنان APPROVED می‌ماند. rejection آشکار بخشی از evidence contract است.

12. مسیر مثبت Baseline

baseline مسیر DRAFT -> SUBMITTED -> ON_HOLD -> SUBMITTED -> APPROVED را اجرا می‌کند. این مسیر در محدوده‌ی fixture نشان می‌دهد یک guard، یک hold قابل resume و یک terminal boundary مطابق مدل رفتار می‌کنند. classification مورد انتظار BOUNDED_FLOW_COMPLETED است.

13. Evidence Record

هر ردیف تصمیم این فیلدها را حفظ می‌کند: Current State، Trigger، Guard، Next State، Hold or Terminal، Side Effect، Invalid Alternative، Evidence و Recovery or Resume Rule. observation اجرایی باید از inference معماری یا domain جدا بماند.

14. کامل بودن Evidence

اگر Recovery or Resume Rule حذف شود، semantics مربوط به hold قابل audit نیست. probe evidence_field_removed در این حالت EVIDENCE_INCOMPLETE برمی‌گرداند. سبز بودن یک transition به‌تنهایی برای تصمیم نهایی کافی نیست.

15. Graph Inspection با Runtime Enforcement یکی نیست

transition table یا diagram می‌تواند edgeهای مورد انتظار را نشان دهد، اما ثابت نمی‌کند implementation واقعاً guardها را enforce می‌کند. fixture اجرایی evidence محلی enforcement است و visual فقط representation آموزشی همان contract محدود است.

16. مرز Prerequisite

DAT-010 prerequisite سخت برای bounded contract reasoning را فراهم می‌کند. DAT-018 prerequisite نرم برای durable intent و recovery thinking است. این درس outcome مربوط به outbox را دوباره آموزش نمی‌دهد و فقط discipline مربوط به evidence صریح و recovery rule محدود را reuse می‌کند.

17. Source Boundary و Freshness

source boundary منجمد شامل دقیقاً سه صفحه از مستندات AWS Step Functions است: ساختار state machine، Choice state و Succeed state. این منابع فقط به‌عنوان مثال vendor برای named state، conditional transition و terminal behavior استفاده می‌شوند. snapshot در 2026-09-02 گرفته شده و review بعدی 2026-10-17 است. در 2026-09-16 recheck لازم نیست و Query 1 بدون scope expansion همان boundary را حفظ می‌کند.

18. Transfer با Context جدید

یک payout workflow چهار state دارد: PENDING، NEEDS_REVIEW، RELEASED و CANCELLED. یک guard تعریف کنید، مشخص کنید NEEDS_REVIEW واقعاً hold قابل resume است یا نه، و terminal boundaryها را تعیین کنید. اسم‌های review-request را کپی نکنید؛ decision rule را منتقل کنید.

19. تصمیم محدود نهایی

fixture محلی می‌تواند stateهای صریح، guard enforcement، hold قابل resume، terminal boundary و rejection آشکار illegal transition را نشان دهد. این fixture global liveness، deadlock freedom، business authorization خارج از guardهای مدل‌شده یا ضرورت استفاده از State Machine برای همه workflowها را ثابت نمی‌کند.