Safe Workflow Lab

1) مسئله: workflow روی کاغذ امن نیست

یک workflow ممکن است روی نمودار کاملاً منطقی به‌نظر برسد، اما وقتی retry، approval قدیمی، automation، stateهای متناقض و side effect واقعی هم‌زمان شوند، رفتار خطرناک ظاهر می‌شود. بدترین روش برای کشف این خطاها این است که مستقیم روی محتوای واقعی یا endpoint انتشار آزمایش کنیم؛ چون هم replay سخت می‌شود و هم یک خطای تست می‌تواند به mutation واقعی تبدیل شود.

در این درس Safe Editorial Workflow Lab Harness v1 را می‌سازیم: یک محیط آفلاین و synthetic که transitionها، approval/revision binding، role boundary، idempotency، fault injection، audit trail و side-effect firewall را قبل از هر release واقعی آزمایش می‌کند.

قانون مرکزی: Lab باید بتواند failure را واقعی‌نما کند، اما نباید بتواند side effect واقعی تولید کند.

2) مرز درس

COM-019 مالک «Safe Workflow Lab» است. COM-018 مالک Client Approval States و Revision Branching است و COM-020 مالک Guided Onboarding و Progressive Disclosure. این درس approval model یا onboarding را دوباره طراحی نمی‌کند؛ آن‌ها را به‌عنوان ورودی محدود آزمایش می‌کند.

این درس همچنین مجوز انتشار واقعی، دسترسی production، credential، billing mutation یا تغییر tenant ایجاد نمی‌کند. خروجی آن شواهد قابل‌replay برای human release review است، نه release authority.

3) مدل ذهنی: Fixture → Event → Assertion → Replay → Human Review

برای هر run این زنجیره را حفظ کن:

1. fixture synthetic و version‌شده؛
2. initial state مشخص؛
3. event sequence قطعی؛
4. actor role و transition contract؛
5. expected و actual state؛
6. approval متصل به revision درست؛
7. side-effect mode بسته؛
8. idempotency key برای retry؛
9. fault injection صریح؛
10. audit event و assertion؛
11. replay reference؛
12. نتیجهٔ bounded برای بازبینی انسانی.

4) چرا synthetic fixture لازم است؟

Fixture خوب فقط «دادهٔ تست» نیست؛ snapshotی است که یک run را قابل‌تکرار می‌کند. اگر ورودی‌ها، workflow version، event order یا revision مرجع عوض شوند اما ثبت نشوند، شکست بعدی دیگر قابل‌مقایسه نیست.

در این Lab، هر fixture باید شناسهٔ مستقل، item synthetic، workflow version و evidence ref داشته باشد. شناسه‌های واقعی مشتری، token، API key و endpoint production ممنوع‌اند. این محدودیت ضعف Lab نیست؛ بخشی از safety contract آن است.

5) provenance: چه چیزی، توسط چه کسی، در کدام activity؟

W3C PROV-O سه مفهوم پایهٔ Entity، Activity و Agent را برای نمایش provenance معرفی می‌کند. در این درس از این مدل به‌عنوان یک الگوی provenance استفاده می‌کنیم: fixture و artifact می‌توانند Entity باشند، اجرای transition یک Activity و actor/test runner یک Agent.

این استاندارد به‌خودی‌خود نمی‌گوید workflow شما امن است یا idempotency چگونه طراحی شود. آن بخش‌ها تصمیم طراحی MAKNOW هستند. استفادهٔ ما محدود است: lineage قابل‌ردیابی برای run و evidence.

6) workflow automation را از authority جدا کن

مستندات فعلی Contentful نشان می‌دهد workflow می‌تواند stepهای مشخص داشته باشد و به rule/action، notification، task و automation متصل شود. این یک FACT دربارهٔ قابلیت یک platform است، نه مجوز معماری برای MAKNOW.

پس اگر یک automation از validation عبور کرد، هنوز حق انتشار ندارد مگر اینکه contract محلی، revision binding، assertionها و human release gate هم عبور کرده باشند. Vendor capability با release authority یکی نیست.

7) side-effect firewall

در Safe Workflow Lab، side_effect_mode باید BLOCKED یا معادل کاملاً no-op باشد. حتی اگر همهٔ assertionها PASS شوند، evaluator نباید بتواند publish، email واقعی، payment، webhook بیرونی یا mutation روی CMS واقعی انجام دهد.

یک الگوی امن:

• adapterهای live با fake adapter جایگزین شوند؛
• hostname/endpoint واقعی اصلاً وارد fixture نشود؛
• هر action بیرونی به event مصنوعی تبدیل شود؛
• وجود LIVE_PUBLISH, LIVE_WEBHOOK یا credential واقعی فوراً state را BLOCKED کند؛
• human release بعداً خارج از Lab و با authority مستقل انجام شود.

8) idempotency و retry

Retry طبیعی است؛ duplicate side effect طبیعی نیست. اگر یک transition دوباره اجرا شد، idempotency key باید نشان دهد که همان operation قبلی است. بدون این binding، duplicate approval event، duplicate notification یا double transition ممکن است رخ دهد.

در Lab، mutation ساده‌ای داریم: همان transition را دو بار replay می‌کنیم. اگر idempotency protection حذف شود، نتیجه نباید موفقیت باشد؛ باید BLOCKED_IDEMPOTENCY یا state محدود مشابه برگردد.

9) approval قدیمی یعنی approval معتبر نیست

Approval باید به revision مشخص متصل باشد. اگر client revision r17 را approve کرده اما item بعداً به r18 تغییر کرده، reuse کردن approval قبلی unsafe است. Lab باید این mismatch را به‌صورت deterministic تشخیص دهد.

این failure با «اعتماد به reviewer» حل نمی‌شود؛ با evidence حل می‌شود: approval_revision_ref باید با revision فعال fixture برابر باشد. در غیر این صورت state باید STALE/BLOCKED باقی بماند تا review جدید ثبت شود.

10) failure injection و audit completeness

Lab خوب فقط happy path را اجرا نمی‌کند. حداقل باید این failureها را عمداً تزریق کند:

• side effect واقعی فعال شود؛
• approval revision قدیمی شود؛
• duplicate event بدون idempotency replay شود؛
• event شکست‌خورده از audit حذف شود؛
• expected و actual state mismatch کنند؛
• evidence حیاتی حذف شود.

هر failure باید در audit trail دیده شود و replay قابل‌ساخت باشد. حذف failure از audit، حتی اگر final state درست باشد، نتیجه را ناقص می‌کند چون تصمیم دیگر قابل‌ممیزی نیست.

11) Evidence Contract و state vocabulary

Artifact این درس 22 فیلد دارد: lab_run_id, fixture_set_id, workflow_version, synthetic_item_id, initial_state, event_sequence, actor_role, transition_id, expected_state, actual_state, approval_revision_ref, evidence_fixture_ref, side_effect_mode, idempotency_key, fault_injection, retry_count, audit_event_ids, assertion_result, replay_ref, failure_class, owner, evidence_ref.

18 فیلد برای تصمیم بحرانی‌اند. stateهای موفق یا محدود باید از evidence بیایند، نه از ترجیح طراح. vocabulary عملی این Lab شامل READY_FOR_HUMAN_RELEASE_REVIEW, HOLD_MISSING_EVIDENCE, BLOCKED_SIDE_EFFECT, BLOCKED_STALE_APPROVAL, BLOCKED_IDEMPOTENCY, BLOCKED_ASSERTION, PARTIAL_AUDIT_GAP و BLOCKED_SCOPE است.

12) Lab و تمرین انتقال: legal-review اختیاری

Lab آفلاین 8 fixture دارد. هر fixture شش invariant اصلی را بررسی می‌کند و oracle داخلی 48 assertion deterministic اجرا می‌کند. هیچ network call، credential یا دادهٔ customer وجود ندارد.

تمرین انتقال: برای صفحه‌های regulated یک branch اختیاری legal-review اضافه شده است. باید دو چیز هم‌زمان درست باشد:

• regulated content بدون legal evidence نباید release-ready شود؛
• non-regulated content نباید به‌اجبار وارد legal-review شود.

پس branch باید به content_class و evidence روشن bind شود، نه اینکه به همهٔ itemها globally تحمیل شود. اینجا baseline answer oracle نیست؛ fixture تغییر کرده و decision باید از نو محاسبه شود.

13) جمع‌بندی و معیار عبور

Safe Workflow Lab یعنی شکست را قابل‌تکرار، قابل‌ردیابی و بدون side effect واقعی کنیم. run زمانی فقط برای human release review آماده است که critical evidence کامل باشد، side effect بسته بماند، revision binding معتبر باشد، retry idempotent باشد، expected/actual state سازگار باشد، audit کامل باشد و replay ref موجود باشد.

خروجی این درس publication نیست؛ یک evidence package قابل‌ممیزی است که انسان می‌تواند از روی آن تصمیم بعدی را بازسازی کند.

منابع و تازگی

• Contentful Help Center, Workflows / Workflow steps / Workflow automations — rechecked 2026-09-15.
• W3C, PROV-O: The PROV Ontology — foundational Recommendation, rechecked 2026-09-15.
• قواعد fixture، side-effect firewall، idempotency gate و human release authority در این درس DESIGNهای MAKNOW هستند و به vendor/standard نسبت داده نمی‌شوند.