Public Release Manifest و Exact Assets

1. Release identity را از URL و filename جدا کن

فرض کن یک release عمومی شامل JSON فارسی و انگلیسی، دو تصویر و یک stylesheet است. اگر همه فایل‌ها با همان نام قبلی روی CDN دیده شوند، هنوز ثابت نشده که همان bytes بررسی‌شده در review منتشر شده‌اند. URL و filename محل تحویل هستند؛ release identity باید به manifest version، manifest digest و descriptorهای exact asset متکی باشد. اگر bytes پشت یک URL ثابت عوض شوند، release باید fail-closed شود حتی اگر صفحه ظاهراً سالم باشد.

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

CON-005 فقط Public Release Manifest & Exact Asset Set v1 را مالک است: release ID/version، manifest digest، required asset set، asset role، media type، byte size، digest، locale/variant و referenceهای source/claim/rights/approval. CON-001 مرجع source/version را تعیین می‌کند؛ CON-002 claim evidence را؛ CON-003 rights/embargo را؛ CON-004 approval validity را؛ CON-006 تا CON-010 route و rollback عمومی را. این درس evidence آن‌ها را bind می‌کند، ولی تصمیم آن درس‌ها را دوباره اختراع نمی‌کند.

3. Descriptor را واحد exact asset بدان

برای هر asset یک descriptor صریح بساز: role، logical_name، media_type، size و digest. الگوی OCI مفید است چون descriptor را با media type، digest و byte size تعریف می‌کند و مصرف‌کننده می‌تواند bytes را دوباره verify کند. MAKNOW ادعا نمی‌کند release manifest خودش OCI image manifest است؛ فقط pattern content-addressed را برای جلوگیری از ابهام filename/URL به‌کار می‌گیرد.

4. digest بدون size کافی نیست

اگر digest expected با bytes observed تطبیق داشته باشد ولی اندازه اعلام‌شده متفاوت باشد، descriptor ناسازگار است. برعکس، size برابر هم بدون digest چیزی درباره exact bytes ثابت نمی‌کند. در matrix این درس، digest_verified و size_verified هر دو ثبت می‌شوند و byte_identity_ok فقط وقتی true است که هر دو برای همه assetهای required پاس شوند.

5. required asset set را قبل از verify قفل کن

قبل از fetch یا promotion باید معلوم باشد release دقیقاً چه چیزهایی لازم دارد. اگر بعداً یک فایل locale جدید required شود ولی candidate manifest آن را list نکند، مسئله «فایل پیدا نشد» نیست؛ مسئله completeness failure است. required set باید versioned باشد تا reviewer بداند absence یک asset واقعاً مجاز بوده یا از manifest جا افتاده است.

6. نقش و locale/variant را بخشی از composition کن

دو فایل ممکن است digest متفاوت ولی نام مشابه داشته باشند یا یک تصویر desktop و mobile از یک source باشند. descriptor باید role، locale و variant را حفظ کند تا composition قابل بازسازی باشد. digest فقط می‌گوید «کدام bytes»؛ role و locale می‌گویند «این bytes در release چه وظیفه‌ای دارند».

7. mutable locator فقط delivery hint است

https://cdn.example/.../hero.jpg می‌تواند امروز به یک digest و فردا به digest دیگری اشاره کند. پس locator را نگه دار، اما authority را به آن نده. promotion pipeline باید object را از locator یا store بگیرد و observed digest/size را با descriptor مقایسه کند. همان filename با bytes جدید باید BLOCK_DIGEST_MISMATCH شود.

8. source، claim، rights و approval را مستقل bind کن

هر asset یا release باید referenceهای لازم مثل source_binding_ref، claim_set_ref، rights_decision_ref و approval_validity_ref را داشته باشد. این referenceها evidence خودشان را تولید نمی‌کنند؛ فقط release را به تصمیم‌های versioned بالادستی وصل می‌کنند. اگر approval revoked شود، bytes می‌توانند هنوز دقیق باشند ولی release دیگر ready نیست.

9. exact bytes و governance دو محور جدا هستند

byte_identity_ok=true به‌تنهایی به معنی مجاز بودن انتشار نیست. ممکن است bytes دقیق باشند ولی rights embargoed یا source unbound باشد. برعکس، approval و rights ممکن است معتبر باشند ولی CDN object تغییر کرده باشد. مدل درست دو محور را جدا نگه می‌دارد و RELEASE_READY را از intersection آن‌ها می‌سازد.

10. manifest digest خود composition را bind می‌کند

بعد از مرتب‌سازی canonical descriptorها و metadata تصمیم، از manifest یک digest تولید کن. این digest identity نسخه release را می‌بندد. اگر exact asset set تغییر کند، manifest version و manifest digest جدید لازم است؛ manifest تاریخی نباید درجا mutate شود. این کار rollback و audit را ممکن می‌کند چون release قدیمی هنوز قابل بازسازی است.

11. SRI را درست محدود کن

Subresource Integrity نمونه‌ای از bind کردن یک web subresource به integrity metadata رمزنگاری‌شده است. این مفهوم برای exact-resource verification مفید است، ولی SRI یک release-governance system کامل نیست: required locale set، rights، approval و source provenance را مدیریت نمی‌کند. بنابراین از آن به‌عنوان شاهد K3 استفاده می‌کنیم، نه جایگزین manifest MAKNOW.

12. decision stateها را typed نگه دار

در این درس success واحد نداریم. نمونه stateها: RELEASE_READY، BLOCK_DIGEST_MISMATCH، BLOCK_ASSET_MISSING، BLOCK_APPROVAL_INVALID، BLOCK_RIGHTS_INELIGIBLE، BLOCK_SOURCE_UNBOUND و BLOCK_MANIFEST_VERSION. reason باید دقیقاً بگوید کدام evidence شکست خورده است تا تیم بعدی فقط همان slice را repair کند.

13. مثال منفی: filename ثابت، bytes جدید

تصویر hero-fa.webp در review با digest sha256:A تأیید شده است. بعد از review، همان URL با digest sha256:B overwrite می‌شود. اگر pipeline فقط URL/filename را چک کند، release اشتباه publish می‌شود. اگر descriptor را verify کند، byte_identity_ok=false و promotion متوقف می‌شود—even if rights and approval remain valid.

14. Transfer: derivative جدید و locale asset جدید

همان release family را نگه دار، اما یک تصویر را با derivative تازه و approved جایگزین کن و یک asset جدید برای locale de اضافه کن. این تغییر composition است؛ پس manifest version و manifest digest تازه لازم است. release قدیمی historical و reproducible می‌ماند؛ release جدید باید completeness، digest verification و governance refs را از صفر برای set جدید ببندد.

15. خروجی قابل ممیزی

خروجی نهایی Public Release Manifest & Exact Asset Set v1 است. reviewer باید بدون دیدن UI بتواند پاسخ دهد: required assetها کدام‌اند؟ هر asset چه role/media type/size/digest دارد؟ locator چیست؟ source/claim/rights/approval به کدام نسخه bind شده‌اند؟ present و verified هستند؟ manifest identity جدید است؟ و چرا decision نهایی ready یا blocked است؟ هر UNKNOWN یا revoked state باید صریح بماند و هیچ filename، URL یا green badge حق تبدیل آن به موفقیت ندارد.