Packing Queue و Fulfillment Priority

وقتی «فوری» بودن، صف را ناامن می‌کند

سه fulfillment هم‌زمان وارد packing می‌شوند. یکی فقط ۳۵ دقیقه تا cutoff حامل زمان دارد؛ دومی چهار ساعت در صف مانده اما inventory آن کامل نیست؛ سومی را یک نفر در UI با برچسب «خیلی فوری» بالا کشیده ولی هیچ authority یا reason ثبت‌شده‌ای ندارد. اگر صف فقط FIFO باشد، cutoff از دست می‌رود. اگر فقط urgency باشد، کار blocked وارد packing می‌شود. اگر drag-and-drop را حقیقت بگیریم، هیچ‌کس نمی‌تواند بعداً توضیح دهد چرا یک سفارش جلو افتاد.

هدف درس ساخت Packing Queue Priority and Fulfillment Evidence Board v1 است: هر position باید به identity، location، readiness، deadline/cutoff، hold، age، override و starvation evidence وصل باشد. «اولویت بالا» یک مجوز برای دورزدن constraint نیست.

مرز مالکیت COM-031

COM-031 مالک queue eligibility، priority class/reason، override audit و starvation protection برای packing است. COM-030 state machine سفارش را مالک است؛ COM-032 چاپ و verification لیبل را. این درس order state جدید اختراع نمی‌کند و از ranking هم اجازه‌ی چاپ/ارسال نتیجه نمی‌گیرد.

سه خط قرمز:

1. urgent != ready
2. vendor status != local priority authority
3. previous rank != valid rank after location/readiness change

مدل ذهنی: Work identity → Hard constraints → Time risk → Authorized override → Starvation guard → Queue

مسیر قابل ممیزی:

fulfillment identity + assigned location → hold/readiness gates → promised ship-by + carrier cutoff → bounded priority class/reason → authorized override check → starvation guard → queue state → packing evidence

این ترتیب عمداً hard constraints را قبل از urgency می‌گذارد. اگر inventory یا packing readiness معتبر نیست، سیستم نباید با یک score بزرگ‌تر آن را «قابل اجرا» کند. اگر location عوض شد، readiness وابسته به location stale می‌شود و rank باید دوباره محاسبه شود.

FACT، INFERENCE و DESIGN را جدا نگه دار

FACT: مستندات جاری Shopify، fulfillment order را کار fulfillment برای آیتم‌هایی می‌داند که از یک location انجام می‌شوند. پس از order routing، fulfillment orderها ساخته و به locationها assign می‌شوند؛ status و request status هم lifecycle را نشان می‌دهند.

FACT: assignedLocation محل مورد انتظار برای fulfillment است و قبل از شروع کار می‌تواند تغییر کند. Shopify همچنین برای move کردن fulfillment order محدودیت‌هایی مثل lifecycle، موجودی destination، permission و بعضی request statusها دارد.

INFERENCE: چون identity/location و lifecycle می‌توانند تغییر کنند، یک packing queue دفاع‌پذیر باید readiness، deadline/cutoff، location، hold، age و override provenance را به‌صورت fieldهای جدا نگه دارد؛ نه اینکه یک status یا score را همه‌چیز فرض کند.

DESIGN: MAKNOW در این درس hard hold/readiness را قبل از priority می‌سنجد، priority class/reason را deterministic نگه می‌دارد، override را audit می‌کند و برای ready work قدیمی starvation guard دارد. thresholdهای fixture قانون Shopify یا قانون عمومی انبارداری نیستند.

قرارداد ۲۴بعدی Queue Evidence

Gate 1 — Queue item باید fulfillment identity و location داشته باشد

queue_item_id، order_id و fulfillment_order_id را قاطی نکن. یک order می‌تواند چند fulfillment work item داشته باشد. assigned_location باید همان snapshotی باشد که readiness و priority از روی آن محاسبه شده است.

Gate 2 — Hard hold قبل از urgency

اگر blocking_hold فعال است، row وارد queue اجرایی نمی‌شود؛ حتی اگر carrier cutoff نزدیک باشد. priority فقط بین کارهای eligible معنا دارد.

Gate 3 — Inventory Ready و Packing Ready دو evidence جدا هستند

موجودی کامل لزوماً یعنی packing station آماده نیست؛ و آماده‌بودن packing بدون inventory کامل هم کافی نیست. هر دو باید صریح باشند. UNKNOWN یا STALE به true تبدیل نمی‌شود.

Gate 4 — Service level، promised ship-by و carrier cutoff یکی نیستند

service_level انتظار خدمت است؛ promised_ship_by تعهد زمانی shipment؛ carrier_cutoff آخرین فرصت عملیاتی همان pickup/dispatch path. نزدیک‌شدن cutoff می‌تواند دلیل اولویت باشد، اما نمی‌تواند hold را حذف کند.

Gate 5 — به‌جای score مبهم، class و reason قابل توضیح بساز

Fixture از tierهای محدود استفاده می‌کند: P0_CUTOFF_RISK، P1_PROMISE_RISK، P2_STARVATION_GUARD و P3_STANDARD_READY. تصمیم باید یک priority_reason انسانی/ماشینی قابل بازسازی داشته باشد. وزن‌دهی جادویی که معلوم نیست چرا 87 از 100 شده، evidence خوبی نیست.

Gate 6 — Override فقط روی eligible work

override_requested_by به‌تنهایی authority نیست. برای تغییر priority باید override_authority و override_reason معتبر ثبت شود. حتی override مجاز هم inventory/packing hold را دور نمی‌زند.

Gate 7 — Starvation guard از ناپدیدشدن کار کم‌فوریت جلوگیری می‌کند

اگر row آماده است ولی مدت زیادی در صف مانده، باید policy مشخصی برای aging/escalation داشته باشی. starvation guard نباید item blocked را «ready» کند؛ فقط بین eligible work fairness را حفظ می‌کند.

Gate 8 — picked_at و packed_at evidence پیشرفت‌اند، نه علت rank

timestampهای execution کمک می‌کنند queue state و completion را audit کنیم. اما بعد از packed_at، row نباید مثل کار آماده‌ی جدید دوباره prioritize شود.

Gate 9 — location transfer، rank قبلی را stale می‌کند

اگر fulfillment قبل از شروع کار به location دیگری منتقل شد، inventory/packing readiness و cutoff context می‌تواند عوض شود. prior rank oracle نیست؛ evidence جدید را بساز و تصمیم را recompute کن.

Gate 10 — Missing decisive evidence fail-closed است

اگر location، readiness، hold، cutoff یا authority تعیین‌کننده مفقود/نامعلوم باشد، HOLD_UNKNOWN_EVIDENCE یا state ضعیف‌تر را نگه دار. صف نباید برای «تمیزشدن UI» UNKNOWN را success کند.

مثال‌های حل‌شده

1. Ready + cutoff در ۳۵ دقیقه → QUEUE_P0_CUTOFF_RISK

Inventory و packing هر دو ready هستند، hold وجود ندارد، location ثابت است و cutoff نزدیک است. priority_reason=CARRIER_CUTOFF_WITHIN_WINDOW قابل دفاع است.

2. چهار ساعت age ولی inventory ناقص → HOLD_NOT_READY

سن زیاد، service level و حتی override نمی‌توانند readiness را جعل کنند. row از eligibility خارج است تا evidence عوض شود.

3. «فوری» با override بدون authority → REJECTED_UNAUTHORIZED_OVERRIDE

درخواست انسان ثبت می‌شود، اما بدون authority و reason معتبر، rank رسمی تغییر نمی‌کند.

4. Ready و قدیمی بدون deadline نزدیک → QUEUE_P2_STARVATION_GUARD

وقتی row eligible مدت طولانی منتظر مانده، starvation guard آن را بالا می‌آورد تا همیشه پشت سفارش‌های تازه‌تر نماند.

5. Blocking fraud/quality hold با cutoff نزدیک → HOLD_BLOCKING_CONSTRAINT

deadline مهم است، اما evidence خطر/hold سخت‌تر است. urgency مجوز دورزدن کنترل نیست.

6. Transfer به location جدید → RECOMPUTE_LOCATION_CHANGE تا بازسازی evidence

اگر readiness_location هنوز location قبلی است، حتی inventory=true قبلی معتبر نیست. بعد از بازسنجی readiness/cutoff در location جدید، class تازه محاسبه می‌شود.

Failure modeهای رایج

• FIFO به‌عنوان تنها قانون؛
• drag-and-drop UI بدون audit؛
• یک urgency score مبهم برای مخلوط‌کردن hold و deadline؛
• بالا بردن item blocked به‌خاطر cutoff؛
• یکی‌گرفتن inventory readiness با packing readiness؛
• استفاده از service level به‌جای promised/cutoff evidence؛
• override بدون actor/authority/reason؛
• aging بدون starvation policy؛
• reuse کردن rank قبلی بعد از location move؛
• تبدیل UNKNOWN/STALE به success برای خالی‌ماندن صف.

Alternatives و trade-offها

FIFO: ساده و قابل فهم، اما deadline risk و service commitment را نمی‌بیند و blocked item را به‌خاطر سن بالا جلو می‌آورد.

Earliest deadline first: برای تعهد زمانی مفید است، ولی بدون readiness/hold gate می‌تواند کار غیرقابل اجرا را جلو بیندازد.

Weighted score: انعطاف‌پذیر است، اما اگر weightها و vetoها روشن نباشند، explainability ضعیف می‌شود. برای این درس tier + reason خواناتر است.

Manual dispatcher: در exceptionها ارزشمند است، اما اگر override authority/reason ثبت نشود صف به تصمیم شفاهی تبدیل می‌شود.

Strict location queues: ساده‌تر و locality-friendly هستند، ولی بعد از reroute باید readiness و cutoff context دوباره محاسبه شود.

بهترین الگو برای این scope: hard gates → bounded priority class/reason → controlled override → aging/starvation guard.

Experienced bridge: سیزده سؤال review

1. queue item و fulfillment order identity جدا و ثابت‌اند؟
2. assigned location مربوط به همین evidence snapshot است؟
3. fulfillment/request status چه چیزی را ثابت می‌کنند و چه چیزی را نه؟
4. inventory readiness و packing readiness جدا ثبت شده‌اند؟
5. blocking hold قبل از priority اعمال می‌شود؟
6. service level از promised ship-by جداست؟
7. carrier cutoff timestamp/context معتبر است؟
8. priority class از reason قابل بازسازی است؟
9. override actor، authority و reason هر سه حاضرند؟
10. override hard hold را دور نمی‌زند؟
11. starvation guard برای ready work قدیمی تعریف شده؟
12. picked/packed evidence با queue state سازگار است؟
13. بعد از location move واقعاً recompute شده یا rank قبلی reuse شده؟

تمرین هدایت‌شده و مستقل

Lab هشت fixture آفلاین دارد. baseline cutoff-risk را اجرا کن؛ بعد inventory-blocked، unauthorized override، location-change-with-stale-readiness، aged-without-starvation-guard، explicit hold و missing evidence را مقایسه کن.

تمرین مستقل: یک row استاندارد را از LOC-A به LOC-B منتقل کن. در LOC-B cutoff 90 دقیقه دیرتر است ولی packing station هنوز readiness تأیید نکرده. اجازه نداری rank قبلی را copy کنی یا فقط location string را عوض کنی؛ ابتدا readiness/cutoff را rebuild کن، سپس class/reason تازه بساز.

Verification evidence

خروجی قابل‌قبول باید هر ۲۴ dimension را یا مقداردهی کند یا state صریح non-success داشته باشد. hard hold و readiness باید قبل از urgency سنجیده شوند؛ class/reason deterministic باشند؛ override provenance کامل باشد؛ starvation protection فقط روی eligible work عمل کند؛ و location transfer evidence را invalidate/recompute کند.

Lab synthetic و offline است؛ هیچ Shopify shop، WMS، inventory واقعی، API key یا customer data لازم ندارد.

Assessment و transfer

برای پایان درس باید بتوانی:

1. مرز COM-031 را از COM-030 و COM-032 جدا کنی؛
2. Packing Queue Priority and Fulfillment Evidence Board v1 را از fixture بسازی؛
3. inventory-blocked و hard-hold item را با وجود urgency fail-closed نگه داری؛
4. unauthorized override و starvation failure را تشخیص دهی؛
5. fulfillment منتقل‌شده به location جدید را از evidence تازه recompute کنی؛
6. توضیح دهی چرا vendor status، FIFO یا یک score واحد به‌تنهایی priority proof نیست.

منابع و freshness

• Shopify GraphQL Admin API — FulfillmentOrder / lifecycle و order routing؛ rechecked 2026-09-15؛ review due 2026-10-18.
• Shopify FulfillmentOrderAssignedLocation — semantics و تغییر location قبل از شروع کار؛ rechecked 2026-09-15؛ review due 2026-10-18.
• Shopify fulfillmentOrderMove — محدودیت‌های move بر اساس lifecycle، inventory، permission و request status؛ rechecked 2026-09-15؛ review due 2026-10-18.
• قواعد tier، override و starvation در این درس DESIGN محلی MAKNOW هستند و به Shopify نسبت داده نمی‌شوند.