Calendar و Campaign Dependencies

1. تقویم فقط زمان را می‌گوید، نه آمادگی را

رسیدن ساعت 09:00 یعنی trigger زمانی رخ داده است؛ به این معنی نیست که نسخه محتوای درست، derivative درست، approval، rights window و handoff کانال حاضرند. در این درس، زمان یکی از evidenceهاست و هرگز جای dependency state را نمی‌گیرد.

2. مرز مالکیت CON-013

CON-013 هویت event/campaign، revision زمان‌بندی و graph وابستگی انتشار را می‌بندد. CON-011 مالک localization semantics، CON-012 مالک version/derivative lineage و CON-010 مالک rollback عمومی است. این مرز جلوی تبدیل تقویم به یک سیستم همه‌کاره و مبهم را می‌گیرد.

3. UID و SEQUENCE دو نقش جدا دارند

در iCalendar، UID هویت پایدار component را نگه می‌دارد و SEQUENCE revision آن را بیان می‌کند. اگر همان UID با sequence جدید آمده باشد، snapshot وابستگی قبلی نباید بدون بررسی دوباره معتبر فرض شود.

4. DTSTART/DTEND فقط پنجره زمانی هستند

DTSTART شروع event را مشخص می‌کند و DTEND در VEVENT پایان non-inclusive است. این فیلدها درباره approval، rights یا version سازگار چیزی ثابت نمی‌کنند. Calendar semantics را با publication policy یکی نکن.

5. Time zone را به instant قابل مقایسه normalize کن

جابجایی launch بین time zoneها ممکن است ساعت محلی را عوض کند ولی instant واقعی ثابت بماند. readiness نباید با مقایسه naive متن ساعت محلی محاسبه شود؛ schedule evidence باید timezone-aware و قابل normalize باشد.

6. Dependency snapshot باید دقیقاً به revision فعلی bind شود

هر revision تقویم باید به snapshot مشخصی از content version، derivative، locale، approval، rights window و channel handoff اشاره کند. اگر sequence عوض شده ولی snapshot هنوز نسخه قبل را نشان می‌دهد، state برابر STALE است.

7. Edge type را صریح نگه دار: HARD در برابر RECOMMENDED

HARD prerequisite حل‌نشده باید release را WAITING/BLOCK کند. RECOMMENDED dependency ممکن است warning بسازد اما فقط در صورتی که policy همان campaign اجازه دهد می‌تواند release-ready باقی بماند. تبدیل نوع edge یک تغییر policy واقعی است و نیاز به recompute دارد.

8. Content و derivative باید روی نسخه موردنیاز هم‌راستا باشند

اگر campaign package نسخه 22 را می‌خواهد ولی derivative فارسی هنوز از version 21 مشتق شده است، صرف وجود فایل کافی نیست. dependency باید STALE_DEPENDENCY یا version mismatch را نشان دهد.

9. Approval باید به همان artifact/revision متصل باشد

یک approval قدیمی برای نسخه قبلی یا derivative دیگر، approval فعلی نیست. approval_ref باید به همان dependency snapshot قابل trace باشد؛ نبود binding به معنی UNKNOWN/WAITING است، نه PASS.

10. Rights window می‌تواند بعد از calendar start باز شود

اگر event ساعت 09:00 شروع می‌شود ولی rights window ساعت 10:00 معتبر می‌شود، clock arrival مجوز استفاده ایجاد نمی‌کند. state باید تا باز شدن window مسدود یا منتظر بماند.

11. Channel handoff یک dependency واقعی است

ارسال package به channel با acknowledgement آن یکی نیست. اگر email/social/CMS handoff هنوز تأیید نشده باشد و policy آن را HARD بداند، campaign release-ready نیست.

12. PROV برای trace کردن رابطه‌ها مفید است

PROV-O می‌تواند Entity، Activity و رابطه‌هایی مثل wasDerivedFrom را برای provenance نمایش دهد. این vocabulary کمک می‌کند dependency evidence قابل trace باشد، اما خودش critical-path یا authorization کمپین را تعریف نمی‌کند.

13. Stateها را collapse نکن

READY، WAITING، BLOCKED و STALE باید علت مشخص داشته باشند. UNKNOWN را به READY تبدیل نکن و یک green badge را جای همه evidenceها ننشان. تصمیم باید دقیقاً به rowهای matrix قابل برگشت باشد.

14. Lab: هشت fixture و 64 assertion

Lab هشت وضعیت synthetic را بررسی می‌کند: baseline ready، derivative stale، rights-window بسته، handoff بدون acknowledgement، timezone move با instant ثابت، sequence stale، recommended missing و transfer که recommended را HARD می‌کند. برای هر case هشت خروجی مستقل سنجیده می‌شود.

15. Transfer: تصمیم قبلی را کپی نکن

launch را به window timezone-aware جدید ببر، sequence را افزایش بده، derivative جدید جایگزین کن و یک dependency پیشنهادی را HARD کن. readiness باید از snapshot جدید محاسبه شود؛ تصمیم قبلی فقط تاریخچه است، نه پاسخ جدید.