Structured Content Editor / CMS Authoring UX

وقتی Preview درست است ولی Content Contract خراب است

دو نویسنده هم‌زمان روی یک درس کار می‌کنند. نویسندهٔ اول heading structure و assessment block را تغییر می‌دهد. نویسندهٔ دوم، بر پایهٔ revision قدیمی، یک media block بدون alternative text اضافه می‌کند. چند ثانیه بعد autosave نویسندهٔ دوم می‌رسد. اگر CMS فقط «آخرین payload رسیده» را ذخیره کند، تغییر نویسندهٔ اول ممکن است بی‌صدا overwrite شود؛ اگر preview از draft دیگری ساخته شود، صفحه‌ای که reviewer می‌بیند همان چیزی نیست که بعداً publish می‌شود؛ و اگر validation فقط در انتهای publish اجرا شود، نقص accessibility خیلی دیر کشف می‌شود.

در این درس Structured Content Authoring State Machine & Accessible Editor Contract v1 را می‌سازیم: canonical content به‌صورت schema-versioned block/field نگه داشته می‌شود؛ هر autosave به base_revision_id مشخص bind است؛ stale base به conflict branch می‌رود نه overwrite؛ semantics و accessibility metadata قبل از promotion validate می‌شوند؛ review revision صریح انتخاب می‌شود؛ و preview/publish فقط از همان revision اعلام‌شده مشتق می‌شوند.

هدف، ساخت یک editor «زیبا» نیست. هدف ساختن یک authoring UX است که بتواند ثابت کند چه چیزی ویرایش شد، بر اساس کدام revision، چه gateهایی پاس یا fail شدند، reviewer دقیقاً کدام revision را دید، و چه چیزی اجازهٔ publish دارد.

مناسب برای: مهندسان CMS/LMS، طراحان authoring workflow، frontend/backend engineers، accessibility/QA reviewers. مناسب نیست برای: جایگزین‌کردن design system، تولید content واقعی، یا ادعای conformance حقوقی/سازمانی فقط به اتکای این درس.

مسیر یادگیری و مرز مسئولیت

MKN-027 فقط مالک Structured Content Editor / CMS Authoring UX است. prerequisite مستقیم آن MKN-026 است؛ MKN-028 بعداً private Mentor/Reviewer context sharing را می‌گیرد. این درس outcomeهای آن دو را جذب نمی‌کند.

مسیر Foundation با field map و baseline کار می‌کند. مسیر Repair اولین evidence dimension شکسته—مثل stale base، alt text یا preview revision—را جدا می‌کند. مسیر Experienced باید trade-off میان flexibility، conflict safety، accessibility assistance، deterministic preview و migration compatibility را دفاع کند، بدون اینکه همه‌چیز را در یک score مبهم جمع کند.

سه checkpoint: F1 boundary و non-goal را بازگو کن؛ F2 یک shortcut را با field/state دقیق رد کن؛ F3 در schema-v2 transfer، تصمیم را از evidence جدید از صفر recompute کن.

مدل ذهنی: Editor یک State Machine روی Structured Revision است

جریان مرجع:

structured edit → schema validation → accessibility assistance/check → revision + autosave → conflict detection → review revision → deterministic preview → publish gate

شاخهٔ حیاتی:

stale base → conflict branch → preserve both drafts → explicit merge/review، نه last write wins.

سه شیء را جدا نگه دار:

1. Canonical content revision: block/fieldهای schema-versioned با identity پایدار.
2. Authoring draft/autosave branch: کار در حال انجام با base_revision_id صریح؛ هنوز canonical review revision نیست.
3. Review/preview/publish selection: یک revision مشخص که reviewer می‌بیند و renderer از همان می‌سازد.

اگر preview از revision دیگری نسبت به review revision تولید شود، حتی اگر ظاهر «درست» باشد provenance شکسته است. اگر accessibility metadata برای media ناقص است، UX باید کمک و validation بدهد؛ نباید صرفاً اجازه دهد warning در publish ناپدید شود.

در این درس FACT / INFERENCE / DESIGN را جدا می‌کنیم: ATAG/WCAG factهای استاندارد می‌دهند؛ ضرورت هم‌ترازکردن validation و preview با canonical revision یک inference معماری است؛ schema، state machine و migration policy دقیق MAKNOW طراحی محلی‌اند.

قرارداد پایه: Schema، Revision، Validation و Preview Identity

فیلدهای تصمیم‌ساز شامل content_id، content_type، schema_version، block_id، block_type، field_semantics، required_state، validation_state، accessibility_metadata، alt_text_state، heading_structure_state، revision_id، base_revision_id، autosave_revision، conflict_state، author_ref، reviewer_ref، review_state، preview_revision، publish_state، migration_state و audit_event_id هستند.

پنج invariant:

1. Schema explicit: هر revision نسخهٔ schema خودش را اعلام می‌کند؛ block ناشناخته با حدس render نمی‌شود.
2. Revision identity: autosave بدون base_revision_id قابل‌اعتماد نیست؛ base قدیمی باید conflict بسازد.
3. Accessibility before promotion: media بدون alt یا heading structure نامعتبر نمی‌تواند validation_state=PASS معتبر داشته باشد.
4. Preview identity: preview_revision باید همان revision انتخاب‌شده برای review باشد، نه «آخرین draft موجود».
5. Publish bounded: publish فقط بعد از validation و review مناسب و migration state معتبر مجاز است.

Stateهای non-success را واقعی نگه دار: UNKNOWN، UNVERIFIED، STALE، REVIEW_REQUIRED، CONFLICT، HOLD و INSUFFICIENT_EVIDENCE.

طراحی Editor: از Block Semantics تا Conflict-safe Autosave

Structured blocks. author نباید semantics را با font size یا CSS class پنهان کند. heading، assessment، callout و media باید block type و field semantics مشخص داشته باشند. Presentation renderer می‌تواند تغییر کند بدون اینکه معنای canonical content عوض شود.

Schema validation. editor باید هنگام تغییر block، required fieldها و نوع داده را validate کند. validation message باید به block/field دقیق وصل باشد و keyboard-operable باشد؛ modal مبهمی مثل «content invalid» کافی نیست.

Accessibility assistance. ATAG بر accessible بودن خود authoring tool و کمک به تولید محتوای accessible تأکید می‌کند. در CMS/LMS، این یعنی author بتواند با keyboard کار کند و هنگام افزودن media یا ساخت heading structure راهنمایی/validation قابل‌عمل بگیرد. WCAG 2.2 برای محتوای نهایی testable requirementهایی مثل text alternatives، structure و keyboard access دارد؛ اما معماری editor را برای MAKNOW تعیین نمی‌کند.

Revision-aware autosave. هر autosave باید بگوید بر اساس کدام revision ساخته شده. اگر canonical head از R11 به R12 رفته و autosave هنوز base_revision_id=R11 دارد، server نباید payload را روی R12 overwrite کند. باید branch/conflict record بسازد و هر دو version را حفظ کند.

Review selection. reviewer باید revision identity را ببیند. state REVIEWING:R12 بهتر از «preview latest» است، چون latest ممکن است draft دیگری باشد.

Deterministic preview. renderer inputs = exact canonical review revision + declared schema version + deterministic asset bindings. اگر preview revision با review revision برابر نیست، Gate fail می‌شود حتی اگر HTML ظاهراً خوب باشد.

Publish gate. publish نتیجهٔ یک زنجیرهٔ evidence است، نه دکمهٔ مستقل: schema valid، accessibility required fields valid، conflict resolved/contained، review approved، preview identity matched، migration compatible.

مثال کارشده: دو Editor، یک stale autosave، یک media بدون alt

Baseline روی content LESSON-77 و schema v1 است. نویسندهٔ A از R11 شروع می‌کند و heading structure و assessment را اصلاح می‌کند؛ سیستم revision R12 می‌سازد. نویسندهٔ B هم از R11 شروع کرده و media block BLK-M9 را بدون alt text اضافه کرده است. autosave او بعد از ساخته‌شدن R12 می‌رسد.

رفتار درست:

• base_revision_id=R11 و canonical head=R12 → conflict_state=CONFLICT_PRESERVED؛ draft B حذف یا overwrite نمی‌شود.
• media block بدون alt → branch B در accessibility check FAIL می‌شود؛ validation_state=PASS برای آن branch غیرمجاز است.
• reviewer فعلاً R12 را به‌عنوان review_revision انتخاب می‌کند؛ preview فقط از R12 ساخته می‌شود.
• چون conflict branch حل نشده، publish_state=HOLD و bounded decision برابر REVIEW_REQUIRED است.

جدول MKN-027-T1 identity، schema، revision/base، conflict، validation/accessibility، review/preview، publish و migration را کنار هم می‌گذارد. lab://MKN-027/MKN-027-LAB1 همین منطق را روی fixtureهای synthetic اجرا می‌کند.

Failure modeهایی که باید fail-closed شوند

1. stale autosave روی revision جدید overwrite شود → HOLD / STALE_BASE_OVERWRITE.
2. alt text حذف شود ولی validation_state=PASS بماند → HOLD / ACCESSIBILITY_VALIDATION_CONTRADICTION.
3. heading hierarchy نامعتبر باشد ولی accessibility state PASS شود → HOLD.
4. preview از draft revision دیگری غیر از review revision ساخته شود → HOLD / PREVIEW_REVISION_MISMATCH.
5. schema version گم باشد → INSUFFICIENT_EVIDENCE یا HOLD؛ parser نباید حدس بزند.
6. block type جدید زیر schema v1 پذیرفته شود بدون migration/compatibility declaration → HOLD.
7. publish قبل از review approval یا با unresolved conflict انجام شود → HOLD.
8. historical v1 revision هنگام migration به v2 silent rewrite شود → HOLD / HISTORICAL_REVISION_MUTATION.
9. audit event گم باشد → تصمیم کامل قابل replay نیست.

Repair همیشه کوچک‌ترین dimension شکسته را هدف می‌گیرد؛ evidence اختراع نمی‌شود.

پل پیشرفته: Canonical AST + Evented Revisions + Version-aware Renderer

در سیستم بزرگ، structured content را شبیه یک AST/Document Graph canonical مدل کن: blockها identity و semantics دارند و presentation فقط projection است. revision layer تغییرها، base و conflict را نگه می‌دارد؛ validation layer schema/accessibility را بررسی می‌کند؛ renderer revision + schema version صریح می‌گیرد.

این تفکیک یک مزیت مهم دارد: می‌توان UX authoring را بهبود داد بدون اینکه canonical semantics به toolbar یا HTML blob وابسته شود. همچنین conflict handling می‌تواند block-aware باشد، نه فقط رشته‌محور.

برای collaborative editing می‌توان optimistic concurrency، branch/merge یا CRDT/OT را بررسی کرد؛ اما نام pattern به‌تنهایی evidence نیست. در هر گزینه باید بگویی identity، stale base، conflict visibility، accessibility validation و exact preview revision چگونه اثبات می‌شوند.

گزینه‌ها و Trade-offها

Rich-text HTML blob: ساده برای شروع، اما semantics، migration و fine-grained validation ضعیف‌تر و diff/conflict پرنویزتر است. Structured block editor: semantics و validation قوی‌تر؛ نیازمند schema governance و migration discipline است. Last-write-wins autosave: UX ظاهراً نرم؛ خطر data loss و conflict پنهان. Optimistic concurrency + explicit conflict: کمی friction بیشتر؛ provenance و recoverability بهتر. Preview latest draft: ساده، اما reviewer ممکن است چیز دیگری از publish target ببیند. Preview exact review revision: reproducible و audit-friendly؛ نیازمند revision identity و deterministic renderer. Hard-block accessibility errors: assurance بالاتر، ولی باید false positive/author guidance و override governance روشن باشد. Warning-only: friction کمتر، اما نقص critical ممکن است تا publish عبور کند.

هیچ گزینه‌ای را با score کلی پنهان نکن؛ evidence decisive، advisory و escalation trigger را جدا بنویس.

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

تمرین هدایت‌شده: fixture baseline.json را باز کن. برای هر block، schema/version، revision/base، validation/accessibility، conflict و review/preview identity را ثبت کن. بدون دیدن bounded decision، توضیح بده چرا stale autosave overwrite نمی‌شود و چرا media branch با alt گمشده publish را باز نمی‌کند.

تمرین Repair: fixture missing_alt_but_pass.json فقط یک contradiction دارد. اولین field/state شکسته را پیدا کن و minimal repair بده. سپس preview_wrong_revision.json را اجرا کن و تفاوت «render درست» با «render از revision درست» را توضیح بده.

تمرین مستقل: در transfer، schema v2 یک block جدید interactive_code دارد اما lessonهای موجود روی v1 باقی می‌مانند. migration plan بساز که v1 history را preserve کند، v1 renderer را همچنان قابل replay نگه دارد، new v2 content را فقط با declared schema v2 قبول کند و preview/publish را از version صحیح بسازد.

Verification: چه چیزی واقعاً اثبات شده است؟

برای هر اجرا چهار چیز ثبت کن: fixture_id، issueهای deterministic، bounded_decision و evidence refs. Lab synthetic است؛ پس فقط قرارداد authoring را برای fixtureهای مشخص ثابت می‌کند، نه رفتار production editor یا conformance سازمانی.

Baseline باید REVIEW_REQUIRED بدهد: conflict حفظ شده، media branch accessibility failure دارد، preview دقیقاً از review revision ساخته می‌شود و publish HOLD می‌ماند. mutationهای stale overwrite، false accessibility PASS، preview mismatch، missing schema، unknown v1 block، premature publish و missing audit باید fail-closed شوند.

Evidence معتبر از rules و fixtureهای visible می‌آید؛ hidden model reasoning oracle نیست. producer tests جواب سیستم را verify می‌کنند، ولی learner-facing starter answer key ندارد.

Assessment و Transfer: Schema v2 بدون بازنویسی تاریخ

Transfer requirement: block type جدیدی در schema v2 وارد می‌شود، اما lessonهای قدیمی هنوز schema v1 هستند.

راه bounded:

• historical v1 revisionها immutable می‌مانند؛ schema_version آن‌ها عوض نمی‌شود.
• renderer باید بر اساس declared version، v1 یا v2 parser/renderer compatibility path را انتخاب کند.
• new block فقط در v2 معتبر است؛ واردکردن آن به v1 بدون explicit migration باید HOLD شود.
• migration یک new revision ایجاد می‌کند، نه rewrite revision قدیمی.
• preview و publish هر revision را با schema_version همان revision می‌سازند.
• audit link باید old revision، new revision و migration event را trace کند.

Bounded state برای fixture سالم transfer برابر COMPATIBILITY_REVIEW_REQUIRED است: compatibility path و history preservation درست‌اند، اما promotion v2 هنوز review صریح می‌خواهد. fixture silent rewrite باید HOLD شود.

منابع، مرز ادعا و Freshness

1. W3C ATAG Overview authoring tool را شامل CMS/LMS می‌داند و دو مسئولیت را جدا می‌کند: خود ابزار برای authorها accessible باشد و به تولید محتوای accessible کمک کند. صفحه در 14 نوامبر 2025 به‌روزرسانی شده و می‌گوید ATAG 2.0 همچنان relevant است، هرچند خود استاندارد در 2015 منتشر شده است.
2. WCAG 2.2 W3C Recommendation برای accessibility محتوای وب است و success criterionهای testable از جمله text alternatives، info/relationships و keyboard accessibility دارد. نسخهٔ Recommendation فعلی 12 دسامبر 2024 است.
3. schema taxonomy، revision state machine، conflict policy، validation severity، exact-preview rule و migration policy این درس MAKNOW DESIGN هستند؛ ATAG/WCAG این معماری را تجویز نمی‌کنند.

منابع رسمی در 2026-09-13 دوباره بررسی شدند. claimهای practice-evolving باید تا 2027-01-15 یا زودتر پس از تغییر material در guidance بازبینی شوند. package پذیرفته‌شده silent rewrite نمی‌شود؛ canonical change نسخهٔ جدید می‌خواهد.

سؤال پایانی: در editor فعلی شما کدام shortcut false confidence بیشتری می‌سازد—HTML blob، last-write-wins، warning-only accessibility یا preview-latest—and چه field دقیقی آن را آشکار می‌کند؟