improve bazdid 2

docs/visit_hold_entezar.md

@@ -38,8 +38,17 @@
 
 ### قاعدهٔ طلایی: ستون، «مرجع» نیست
 
-> `visit_hold_until` هیچ اعتباری به‌تنهایی ندارد. فقط وقتی اثر دارد که برای همان
-> مشتری یک اقدام **هماهنگیِ فعال** (`waite` یا `finish`) وجود داشته باشد.
+> `visit_hold_until` هیچ اعتباری به‌تنهایی ندارد. یک قرار دستی فقط وقتی اثر دارد
+> که **هر سه** شرط برقرار باشد:
+>
+> ۱. تاریخش از حالا جلوتر باشد،
+> ۲. برای همان مشتری یک اقدام **هماهنگیِ فعال** (`waite` یا `finish`) وجود داشته باشد،
+> ۳. **آخرین فعالیتِ مشتری همان هماهنگی باشد** — اگر بعد از آن، اقدام دیگری
+>    (به‌ویژه «بازدید») ثبت شده باشد، قرار منتفی است.
+
+شرط ۳ برای این است که «ثبت بازدید پس از هماهنگی» قرار را خودکار باطل کند.
+بدون آن، قرار قدیمی تا تاریخش زنده می‌ماند و مشتری در فهرست «با قرار» می‌ماند،
+هرچند بازدید جای هماهنگی را گرفته است.
 
 نتیجهٔ این قاعده:
 
@@ -48,6 +57,7 @@
 | حذف اقدام هماهنگی | قرار **خودکار بی‌اثر** می‌شود |
 | لغو هماهنگی (`cancell`) | بی‌اثر می‌شود |
 | ویرایش تاریخ هماهنگی | قرار با تاریخ جدید هم‌راستا می‌شود |
+| **ثبت بازدید (یا هر اقدام دیگر) پس از هماهنگی** | قرار **خودکار بی‌اثر** می‌شود |
 | کهنه ماندن ستون | **هیچ اثر مخربی ندارد** |
 
 به همین دلیل دیگر خطر «کش کهنه» وجود ندارد: منبع حقیقت همیشه جدول `Action` است.
@@ -58,15 +68,26 @@
 
 تصمیم «مشتری در فهرست هست یا نه» از اجتماع سه منبع گرفته می‌شود:
 
-| منبع | تعریف | تاریخ قرار |
-|---|---|---|
-| `manual` | ستون `visit_hold_until` (با اعتبارسنجی بالا) | همان ستون (پایان روز) |
-| `scheduled` | `bazdid + waite` با تاریخ آینده | `actionDateTime` |
-| `coordination` | `hamahangi` با `waite` یا `finish` و تاریخ آینده | `actionDateTime` (یا `finishDateTime`) |
+| منبع | تعریف | تاریخ قرار | مرز زمانی |
+|---|---|---|---|
+| `manual` | ستون `visit_hold_until` (با اعتبارسنجی بالا) | همان ستون (پایان روز) | پایان امروز |
+| `scheduled` | `bazdid + waite` | `actionDateTime` | **پایان روز** |
+| `coordination` | `hamahangi` با `waite` یا `finish` | `actionDateTime` (یا `finishDateTime`) | **لحظه‌ای** |
 
 تابع واحد: `visit_policy.next_appointment_map(now)` — **همان تابعی که اسکنر پیامک
 هم استفاده می‌کند**، پس صفحه و پیامک هرگز واگرا نمی‌شوند.
 
+**چرا مرز زمانیِ دو منبع فرق دارد؟**
+
+* در `scheduled`، `actionDateTime` یک **قرارِ آینده** است که کارشناس با تقویم
+  روزانه انتخاب می‌کند؛ پس «قرار امروز» باید تا پایان امروز معتبر بماند. با
+  مقایسهٔ لحظه‌ای، بازدیدِ امروز بلافاصله پس از گذشتن ساعتش از فهرست ناپدید
+  می‌شد (باگی که گزارش شد).
+* در `coordination`، `actionDateTime` **زمانِ تماس** است، نه قرار آینده. اگر آن
+  را هم تا پایان روز معتبر بگیریم، هر تماسِ امروز مشتری را تا آخر امروز از
+  گروه «قرار دستی» بیرون می‌برد و سناریوی اصلی (تماس امروز + قرار دو هفته بعد)
+  بی‌اثر می‌شد.
+
 اگر مشتری چند قرار داشته باشد، **زودترین** تاریخ ملاک نمایش است؛ اما برای
 «بازگشت به فهرست» کافی است **آخرین** قرار منقضی شود.