فهرست مستندات
معماری سیستم#
الامر از معماری کمر باریک (narrow waist) استفاده میکند:
Developer Portal / Hub / Environments / Apps / Plugins
|
React and R3F public adapters
|
framework-neutral Al-Amr SDK
|
contracts + Registry API + desktop sessions + grants + presence
|
Registry modular monolith / Environment and App backends / Plugin backend components
کجا پیاده شده است#
packages/contracts/src/index.ts— کمرگاه باریکی که هر سطح این صفحه با آن اعتبارسنجی میکند.services/registry/src/application/create-app.ts— ریشهٔ ترکیبِ رجیستری، و تنها منبع حقیقتی که اینجا نام برده شده است. کنارش یک barrel بود (src/index.ts) که تنها خوانندههایش یک ورودیِ build و یک قاعدهٔ وابستگی بودند؛ حذفش یک نقض مرز را آشکار کرد که همان barrel پنهانش کرده بود، و ورودیِ پروسهsrc/bootstrap.tsاست.packages/sdk/src/bridge-client.tsوpackages/sdk/src/environment-boot.ts— همان SDK که محیط با آن بالا میآید، از راه پلِ سکو.packages/react/src/app-frame.tsx— آداپتور پذیرش App فقط برای مرورگر؛ این AppHost جاری دسکتاپ نیست.platform/desktop/src/main/apps/app-view-manager.ts— AppHost دسکتاپ که bundle نگهداریشدهٔ App را بررسی و باز میکند و مالک نشست پروتکل آن است.packages/r3f/src/EnvironmentCanvas.tsx— سطح رندر.environments/hub/—environment-zero، که فقط از همین مسیرهای عمومی بالا استفاده میکند.ops/staging/— همان تحویل staging مشترک که در انتها توضیح داده شده است.
سطحها#
developer.al-amr.comمستندات و کاتالوگ عمومیِ رندرشده در سمت سرور را ارائه میکند؛ فقط/consoleبه احراز هویت نیاز دارد.registry.al-amr.comمیزبان APIهای کاتالوگ، مدیریت، نشست Runtime، هویت/JWKS، حضور، تنظیمات و بازبینی است.packages.al-amr.comدر ابتدا tarballهای تغییرناپذیر و نشانیپذیر بر پایهٔ محتوا (content-addressed) را ارائه میکند.- هاب (
Hub) محیطی (Environment) با نقشهای تعیینشده توسط سرور است و هیچ import خصوصی یا مسیر ممتازی برای پلاگین (Plugin) ندارد. مسیرهای/z/:slugفقط صحنهای محلی را انتخاب میکنند و زمان اجرای محیط دیگری را نمیسازند.
تماسهای سکو#
تماس یک سرویس سکو است (ADR-0133)، نه قابلیتی از یک دنیای خاص. تماس از طریق
فهرست همراهان با حساب کاربری آدرسدهی میشود، در هر دعوت با گراف همراهی مجاز
میشود و بهشکل CallAlert زندهٔ حساب زنگ میخورد. رجیستری مالک زنگ، پاسخ و رکورد ماندگار
(platform_calls) است؛ سرویس کنترل رسانه یک درِ پذیرش دوم میگیرد که با توکن
شصتثانیهای media_call_admission باز میشود و کلید دامنهاش جفت حساب است نه
دامنهٔ محیط، پس نشست از هر دری جان سالم بهدر میبرد. اپ مستقل تماس نمای همان سرویس است؛ Main اعلان زندهٔ آن را از همساز و lease
مشترک صدای توجه ارائه میکند. هاب دیگر تماس مستقیم درون محیط را نصب نمیکند.
Appها مالک وضعیت تماس پلتفرم نیستند.
تحویل bundle اپ#
اپها باندلهایی با تألیف مستقلاند، نه پکیجهایی که Environment وارد کند و نه
سندهایی که ناشر میزبانی کند. Registry یک revision دقیق و منتشرشده را انتخاب
میکند؛ کلاینت دسکتاپ باندل تغییرناپذیرش را اعتبارسنجی و نصب میکند و سپس آن را
در WebContentsView ایزوله روی alamr-app://<appId>/ با partition ذخیرهسازی
ویژهٔ محصول اجرا میکند. اپ از پل تزریقشدهٔ window.alamr نشست کوتاهعمر خودش
را میگیرد؛ اعتبارنامهٔ Runtime محیط هرگز وارد سند اپ نمیشود.
icon اپ و cover محیط از یک مرز جداگانهٔ رسانهٔ انتشار عبور میکنند. manifest تغییرناپذیر فایل داخل باندل را نام میبرد؛ Registry آن را از archive بازبینیشده میخواند، container و header و ابعاد raster را اعتبارسنجی میکند، metadata را با allowlist بازنویسی و نتیجه را به revision دقیق متصل میکند. DTO عمومی کاتالوگ و پنل فقط descriptor متعلق به Registry را حمل میکند. کروم پلتفرم هرگز تصویری را از URL ناشر بار نمیکند. نشان کوچک App در حال اجرا همچنان glyph بستهای است که پلتفرم میکشد، نه icon کامل کارت کاتالوگ.
هر اپ Compact دارد و میتواند Workspace را بهعنوان presentation عریض همان سند اعلام کند. Workspace فاصلهٔ طراحیشده را حفظ میکند و fullscreen نیست. تغییر حالت presentation را درجا بهروز میکند؛ اپ باید به presentation میزبان subscribe کند و آن را نشست تازه نداند. پنل پلتفرم مالک chrome، focus، input capture، animation، confirmation و deadline چرخهٔ حیات است و Environment فقط state تایپشدهٔ تعامل پنل را از Adapter عمومی میگیرد.
پل تزریقشده narrow waist نسخهبندیشدهٔ Host Services باقی میماند. Registry قابلیت و رضایت را authorize، main process دسکتاپ آن را enforce و Environment Adapter واقعیت spatial context و navigation را تعیین میکند. واژگان پایدار Zone/location بخشی از revision تغییرناپذیر محیط است. اپ بهجای scene inspection یا coordinate، مرجع semantic یا locator opaque و متصل به نسخه ذخیره میکند.
بکاند اپ به قراردادها و ابزار استعلام نشست اپ در پکیج backend وابسته است، نه به محیط یا پنل پلتفرم. دادهٔ پایدار در بکاند اپ میماند؛ storage داخل partition محصول cache است و هرگز هویت یا اختیار portable نیست. ترکیب اپ با پلاگین و نمایش اپ در فضای سهبعدی قراردادهای عمومی آیندهاند، نه APIهای پنهان میزبان.
Registry یک projection ماندگار Notification Subject را هم مالک است. event بازبینیشدهٔ App یک Occurrence idempotent را signal میکند و رجیستری آن را روی ردیف Center کلیددار یا per-occurrence reduce میکند. Subject کلیددار ordering monotonic منبع و acknowledgement watermark دارد. App باز از session خودش استفاده میکند و backend App، Project token محدود را با delegation opaque مخصوص کاربر ترکیب میکند. مسیرهای additive قدیمی App و Environment همچنان فقط هویت بازبینیشدهٔ منبع، event اعلامشده، plain text محدود و action معنایی بسته را میپذیرند.
Desktop Main، Center کامل حساب را از device plane میخواند. Environment Widget فقط projection همان Environment را میبیند و محتوای کامل حساب را نمیگیرد. Realtime فقط invalidation بدون محتوا را حمل میکند؛ Pulse یک تصمیم جدا برای presentation زنده است و state رجیستری authoritative میماند. CallAlert دارای deadline و push خارجی آینده planeهای جدا هستند، نه ردیف Inbox.
بکاند متعلق به Environment#
Environment میتواند در revision تغییرناپذیر خود یک مرز بکاند شامل audience، endpoint، health URL، scopeهای Grant، schema محدود context و disclosureهای داده اعلام کند. این سرویس دادههای اختصاصی مقصد، مانند همایشها و نقش برگزارکننده را مالک میشود و Plugin یا محصول مستقل کاتالوگ نیست.
SDK مرورگر یک EnvironmentBackendGrant کوتاهعمر میگیرد. Registry آن را به
revision دقیق، Runtime فعال، origin باندل میزبانیشده در دسکتاپ، actor جفتی و
endpoint اعلامشده مقید میکند. @al-amr/backend امضا را بررسی و بهطور پیشفرض
Runtime را introspect میکند. ادمین اولیه از مالک Project میآید؛ نقشهای
دامنهای در بکاند Environment میمانند.
ترکیببندی Hub#
هاب همان محیط معمولی env_hub باقی میماند. ناحیه (Zone) صحنهای محلی در
برنامه است: همهٔ ناحیهها مبدأ (origin)، نشست زمان اجرا، هویت حضور
(Presence)، تنظیمات و نصبهای دقیق پلاگین، بازنگری تغییرناپذیر محیط و یک Canvas
پایدار R3F را به اشتراک میگذارند. جابهجایی میان ناحیهها مسیریابی محلی و
فهرستمجازشده است؛ برای ورود به یک Environment مستقل، Shell دسکتاپ bundle دقیق
فعال و نگهداریشده را resolve میکند و مقصد
alamr://environments/<environmentId> را با نشست Runtime تازه باز میکند.
مقصد بازگشت دسکتاپ فقط Environment امن Hub را مشخص میکند. Hub پیش از یک خروج
صریح میتواند checkpoint نسخهدار و یکبارمصرفی را در sessionStorage همان تب
فعال کند که ناحیه، وضعیت مکانی بازیکن و نمای دوربین را نگه میدارد. هنگام بازگشت،
هاب این دادهٔ محلی را با سطح فعلی ناحیه اعتبارسنجی و حل میکند و پیش از mountشدن
Player Rig یا Multiplayer آن را اعمال و سپس مصرف میکند. checkpoint هرگز وارد
URL، توکن زمان اجرا، رکورد رجیستری یا محیط مقصد نمیشود و دادهٔ غایب یا نامعتبر
به نقطهٔ آغاز تألیفشده برمیگردد.
هاب مالک گراف ناحیهها، دادههای زمین و مسیر، نقاط آغاز، هندسهٔ لندمارکهای تألیفشده، موجودی محدود اسلاتهای منطقی و ترکیببندی است. Registry فقط تخصیص فعلی یک اسلات منطقی موجود به شناسهٔ پایدار Environment و تاریخچهٔ ممیزی مدیر را مالک است و نمیتواند هندسه بسازد یا جابهجا کند. قابلیتهای قابل استفادهٔ مجدد از همان مسیر عمومی پلاگینهای R3F میآیند که در اختیار هر محیط قرار دارد:
Hub جایگذاریهای عمومی و کاتالوگ عمومی Environment را با هم میخواند. تخصیص
فقط وقتی قابل ورود است که مقصد آن revision فعال، منتشرشده، عمومی و دقیقاً واجد
شرایط کاتالوگ داشته باشد. اسلات دستی خالی open است؛ تخصیص گمشده، فاقد شرایط
یا غیرقابل تأیید reserved میشود و مقصد ورود افشا نمیکند. در دسترس نبودن
assignment هرگز باعث fallback به مقصد checked-in نمیشود. اتصالهای fixed
فقطخواندنی میمانند و مدیر Registry فقط اسلات manual تألیفشده را با API
مشترک Admin Panel و CLI set، replace یا clear میکند.
- Player Rig آواتار، ورودی دسکتاپ قابلتنظیم، حرکت، پرواز، adapter انیمیشن و دوربین ترکیبی، منبع local replica بدون تخصیص حافظه و Fleet نمونهسازیشدهٔ اختیاری برای replicaهای دوردست را فراهم میکند.
- آسمان، زمین، پوشش گیاهی، هر دو جاده، مسیر قدسی آسمانی، دروازههای مقطع،
نمایش لندمارک، نزدیکی پرتال و تابلوها art تألیفشدهٔ خود ناحیهاند و در هاب
میمانند. همهٔ آنها از
ZoneSurfaceModelمشترک نمونهبرداری میکنند و پلاگین مستقل و بدون مصرفکننده نیستند. ADR-0060 پلاگینهایی را که زمانی آسمان، پراکندگی و نزدیکی پرتال را داشتند بازنشسته کرد: تنها مصرفکنندهٔ هر سه، هاب بود.
این انتشارها، پلاگینهای مستقل frontend_only از نوع کتابخانهٔ مورد اعتماد
(trusted_library) هستند. به یکدیگر وابسته نیستند و کد هاب را import نمیکنند؛
هاب دادهها و callbackهای نوعدار را در اختیارشان میگذارد و هر انتشار نصبشده
را به نسخهای دقیق مقید میکند.
هر ناحیه پیش از mount شدن renderer تنبل خود، یک سیاست رندر — نگاشت سطح کیفیت، backend و کاهش حرکت به هزینهٔ واقعی صحنه — و یک مانیفست صحنه از سیستمهای جهان را resolve میکند. سیستمها سیاست resolveشده را میخوانند نه سطح کیفیت را؛ بنابراین تعویض یا تنظیم دوبارهٔ یک قابلیت بصری نیازمند کپیکردن کل ناحیه نیست.
Multiplayer یک پلاگین full-stack مستقل است: هاب Browser Core مستقل از renderer
را از راه semantic portهای ساختاری با Player Rig ترکیب میکند، اما هیچکدام
دیگری را import نمیکند. هاب شناسهٔ پایدار ناحیهٔ فعال را بهعنوان scope مبهم
میفرستد. بکاند محافظتشده با Grant، environmentId امضاشده و آن scope را به
یک اتاق تکنویسندهٔ hashشده تبدیل میکند، state کامل transform را با آهنگ ثابت
و دودویی میپذیرد و در هر tick برای هر گیرنده یک batch شخصیسازیشدهٔ AOI
میفرستد. leaseهای RoomDirectory در Redis مالکیت چند نود و مبدأ خصوصی مسیریابی مالک را
حصار میکشند. Gateway غیرمالک کاربران را با یک session تجمیعشده و دارای احراز هویت
متقابل HTTP/2 بهازای هر مالک و یک stream محدود بهازای هر مرورگر عبور میدهد؛ Redis
هیچ poseای حمل نمیکند. Browser Core در مرورگرهای مدرن WebSocket، decode دودویی، ساعت
شبکه و backpressure کلاینت را در module Worker داخلی اجرا میکند و سپس ring bufferهای
مبتنی بر ساعت سرور را روی main thread بهروز میکند. تغییر تأخیر tierها روی یک خط
زمانی پیوستهٔ نمایش بهتدریج اعمال میشود. v3 حالت صریح grounded/flying را حمل
میکند، snapshot عضویت را اتمیک commit میکند و Grantهای تازهٔ یکبارمصرف را با
exact-CAS حصار actor روی همان socket تمدید میکند. transitionهای dormant، wake و
mode از cadence عبور میکنند؛ packet gap و dormancy آواتار نمایشدادهشده را حفظ
میکنند. Player Rig هر buffer را یک بار در callback فریم Fleet نمونهسازیشده
میخواند، نه با mount کردن یک آواتار React برای هر peer.
واحد ظرفیت مرجع ۱۵۰ اعتبار participant و ۱۶ اعتبار اتاقِ غیرخالی دارد؛ یک اتاق میتواند هر ۱۵۰ participant را مصرف کند. descriptor مالک اتاق خالی میتواند برای grace شصتثانیهای reuse باقی بماند، بیآنکه اعتباری مصرف کند. Browser Core پیش از ترک Zone فعلی Grant مقصد را میگیرد، تا release تأییدشدهٔ عضویت قبلی صبر میکند و scope جدید را فقط پس از snapshot اتمیک و کامل commit میکند. Zoneهای محدود از binding پذیرش backend خود Environment استفاده میکنند؛ Multiplayer هرگز دسترسی را از مختصات یا route رابط کاربری حدس نمیزند.
اتصال مجدد در همان اتاق یک handoff اتمیک transport است، نه پذیرش عضو جدید. Grant تازه و resume ticket چرخان میتوانند WebSocket قدیمیِ همپوشان را جایگزین کنند؛ دقیقاً یک برندهٔ CAS حق تغییر roster را دارد. تمدید عادی Grant، socket، member، directory یا bufferهای نمایش را جایگزین نمیکند.
Media نیز یک پلاگین مستقل full-stack است و به Multiplayer وابستگی ندارد. Environment
حرکت، Zone و سیاست نزدیکی را از وضعیت Player Rig و Multiplayer مدیریت میکند و فقط
scope مبهم و actorKey انتخابشده را به Media میدهد. کد Environment فقط از
Runtime مدیریتشدهٔ Media استفاده میکند و پیادهسازی خام کنترل و media plane
جزئیات خصوصی پکیج هستند. کنترلپلین محافظتشده با Plugin Grant، دعوت تماس، عضویت
جلسه و استیج، نقشها، مهلت اتصال مجدد و lease یکتای اشتراک صفحه را مدیریت میکند.
رسانه روی LiveKit خودمیزبان منتقل میشود؛
تماس مستقیم و جلسه برای کورماندن SFU رمزنگاری سرتاسری دارند و استیج از رمزنگاری
انتقال استفاده میکند. Registry همچنان مرجع نصب، انتشار و مجوز Runtime است.
Redis مخزن عملیاتی مرجع Media v2.2 برای نشستهای schema-v2، حصارهای کنشگر،
نسخههای اتاق، مهلتهای اتصال مجدد، وضعیت stage، پیشنهادها و leaseها است. هر
گذار، یک کار Projection مستقل و حصارشده با نسخه/مالک را بهصورت اتمیک همگرا
میکند. webhookهای امضاشدهٔ LiveKit، workerهای Projection و full repair عادلانه
با cursor، transport را بدون قراردادن تأخیر ادمین LiveKit در مسیر فرمان با state
مرجع همگرا میکنند.
رابط آواتار از ADR-0041 پیروی
میکند. Player Rig anchorهای معنایی، PlayerAvatarOverlay ثابتپیکسلی و
ارائهکنندههای Fleet/overlay اتاق بزرگ را عرضه میکند؛ Multiplayer توصیفگرهای
peer مهرشده در سرور را ارائه میکند. Media عمداً هیچ مشارکت UI یا سطح composition
ندارد؛ مرز عمومی آن Runtime مدیریتشده، selectorها، متنها و abstraction ترک
native است. Environment دادهٔ Pluginهای همکار را با actorKey مستعار و محدود به
scope تطبیق میدهد و اکشن تماس خودش را برای آواتار تکی در avatar.overhead یا
برای اتاق بزرگ در ریشهٔ projection یکتای avatar.fleet-overhead رندر میکند.
اتصال پردهٔ stage، جایگذاری، دسترسپذیری و fullscreen نیز متعلق به Environment
است. هیچ Plugin دیگری را import نمیکند و API اختصاصی هاب برای attachment وجود
ندارد. مانیفست آداپتور، integration.md رجیستری، declaration بازبینیشده و صفحهٔ
نسخه در Developer Portal دقیقاً همین مرز را برای انسان و عامل کدنویس نمایش
میدهند.
زمین ناحیهٔ fazl یک مقطع درهای متقارن است: fazlValleySectionM تابعی محض از
فاصلهٔ جانبی مطلق تا جاده است، پس هر دو کناره یکسان فرو میافتند و بالا میروند.
مقطع تا ۲۶ متر تخت میماند، سپس نُه متر تا کف علفزار در ۱۲۰ متر فرو میرود و
سرانجام تا یال جنگلیِ پانزده متر بالاتر از جاده در ۲۳۸ متر بالا میرود؛ درست درون
نیمعرض ۲۴۰ متری ناحیه. رهگذری که روی سنگ ایستاده به یک لایه پایین و به لایهٔ بعد
بالا نگاه میکند و در هر فاصله یک صفحهٔ یکسان نمیبیند. هر دو مرحله smoothstepاند،
پس نیمرخ یکنواخت است و تخت به آمیزهٔ کریدور میرسد؛ شکستگی در آن درز، خطی به درازای
جاده میکشید. سیستم پوشش گیاهی آن، پراکندگی blue-noise خوشهای و پیوسته، تنوع بصری،
سطح کیفیت، نمونهسازی و LOD را روی sampler سطح ناحیه و محدودههای ممنوع تألیفشده
مدیریت میکند. سه مقصد Environment از یک نگاشت جایگذاری قابلتعویض resolve میشوند و
در art لندمارک تکرار نمیشوند. مسیر آسمانی، دو آستانهٔ زمینی، متن فارسی
مقطعها، جایگذاری، مسیریابی، ادامهٔ جاده و تابلوی مقطع جاری همگی محتوای
تألیفشدهٔ خود ناحیهاند.
رندرینگ#
محیطهای first-party از طریق نمایهٔ مشترکی رندر میشوند که در
ADR-0048 ثبت
شده است: Three.js r185 با WebGPURenderer مبتنی بر WebGPU و fallback واقعی
WebGL2، یک EnvironmentRenderingGate و EnvironmentCanvas مشترک از
@al-amr/r3f که پیش از mountشدن حضور، پلاگینها یا کد صحنه قابلیت گرافیکی را
probe میکند، مواد سفارشی فقط با TSL و تشخیص امن برای حریم خصوصی. قرارداد کامل
زمان اجرا — حالتها، تلاش مجدد و بازیابی گمشدن دستگاه، کدهای دلیل و سطحهای
کیفیت — در
زمان اجرای رندرینگ آمده است؛ سیاست روبهروی کاربر برای
مرورگر و دستگاه در پشتیبانی از رندرینگ آمده
است.
ذخیرهسازی#
- PGlite پیادهسازی محلی و آزمایشی PostgreSQL است.
- محیط عملیاتی از PostgreSQL در همان مرز دسترسی به داده استفاده میکند.
- Redis در محیط عملیاتی فقط برای حضور زودگذر، محدودسازی نرخ و هماهنگی نشستهای زمان اجرا به کار میرود.
- دادههای حجیم پکیج و رسانه در object storage داخلی و خودمیزبان با پروتکل S3 نگهداری میشوند؛ SeaweedFS مبنای پشتیبانیشده است و حساب آمازون لازم نیست. بایت عمومی پکیج همچنان از مرز توزیع Registry عبور میکند و object store مستقیماً عمومی نمیشود.
- icon مدیریتشدهٔ App و cover مدیریتشدهٔ Environment شیء خصوصی و تغییرناپذیر رسانهاند که اتصال revision منتشرشدهٔ دقیق آنها را مجاز میکند. مسیر عمومی content-addressed آنها VersionId ثبتشده را resolve میکند و هرگز منبع ناشر را بهصورت on-demand proxy نمیکند.
- Registry یک کش مشتقشده و تغییرناپذیر از همهٔ آرتیفکتهای منتشرشده و مجاز Managed Store نگه میدارد. هویت کش شامل SHA-512 مشتقشده از بایتها و VersionId دقیق Object Storage است. وضعیت Registry همچنان هر خواندن را مجاز میکند؛ کش هنگام قطعی provider دانلودهای منتشرشده را حفظ میکند، اما نمیتواند انتشار، upload، draft یا بایتهای مسدودشده را مجاز کند.
هر پاسخ عمومی از وضعیت رجیستری به دست میآید. رابط کاربری و صحنهٔ سهبعدی هیچ رکورد رسمی کاتالوگ را بهصورت ثابت در کد قرار نمیدهند.
استقرار مشترک staging#
staging مشترک سه role استقرار دارد: Core برای اختیار Registry و Developer Portal، Runtime برای بکاندهای متعلق به محصول و سرویسهای پشتیبان، و Media برای LiveKit/Media. بایتهای frontend مربوط به Environment و App باندلهای نگهداریشدهاند، نه سایتهای میزبانیشده در Runtime. PostgreSQL مدیریتشده stateful است؛ Gallery وضعیت محلی host را نگه میدارد؛ state مرجع Media در Redis با AOF پایدار میشود، درحالیکه transport و هماهنگی اتاق LiveKit گذرا و بازسازیپذیر است. این placement صرفاً یک تصمیم عملیاتی staging است و موجودیت عمومی دامنهای تازهای ایجاد نمیکند.
GitLab از یک commit تمیز archiveهای قطعی role را میسازد و symlink محلی current
هر host را زیر systemd/Caddy فعال میکند. وضعیت کاتالوگ Registry، اتصالهای bundle
نگهداریشده و serving state هر role با transaction دارای journal هماهنگ میشود، ولی سیستم ادعای
atomicity میان hostها ندارد. سازگاری N/N-1 و migrationهای expand بازهٔ mixed را
محدود میکنند. منابع typed زیرساخت، deployment profile و کاتالوگ first-party
نماهای deploy را تولید میکنند؛ materialization آدرس field-aware است و source bytes
Plugin یک origin مربوط به staging را در خود embed نمیکند. deployment profileها
pluginOrigins بازبینیشده را از placement زندهٔ service جدا نگه میدارند؛ در نتیجه
جابهجایی backend، BackendDeploymentRevision را جلو میبرد بیآنکه bytes، permission
مانفیست یا SemVer پلاگین را پنهانی تغییر دهد.
سالن کنفرانس و stage
ناحیهٔ fazl چهار Landmark دارد: گالری لومن با شناسهٔ پایدار
env_1317c83f-50a1-4607-9307-b0f852b1a740، سالن کنفرانس با
شناسهٔ پایدار env_f2a8ca72-9584-44dc-b809-6a79587fc176، پارک با
شناسهٔ پایدار env_0632e375-4956-4bf8-8877-3e4fcaa440d6 و سایت ساختوساز
Developer Portal. هر مقصد فقط پس از
حضور active public revision در کاتالوگ قابل ورود میشود. هاب کد محیط را import
نمیکند و URL ورود را نمیسازد.
در Media stage، همه به media:join-space نیاز دارند و فقط Grant دارای
media:publish اختیار انتشار LiveKit و screen-share lease میگیرد. ترتیب ورود
شرکتکنندگان هیچ نقشی ایجاد نمیکند.
تاریخچهٔ مهاجرت رجیستری و بازیابی انتشار 0102#
SQL مهاجرت اجراشده، حتی توضیحات آن، تغییرناپذیر است. migrator مشترک پیش از
اجرای expandهای معلق، checksumهای ثبتشده را بررسی میکند. سرویس میتواند
تراکنش expand معلق را با beforeExpandMigration آماده کند؛ این hook نه بایتهای
SQL را تغییر میدهد و نه checksum دفتر مهاجرت را تطبیق میدهد. رجیستری پیش از
0102 از آن برای اعتبارسنجی بررسیهای deferred مالکیت که 0090 پر کرده استفاده
میکند، سپس index پروندهٔ انتشار را در همان تراکنش بازسازی میکند.
SHA-256 نسخهٔ اصلی 0102_live_publication_case_bridge.sql برابر است با
1f7a5d1b6c9c21805a9998ec4478fc31b071ddc983ff24e7b799fafbe7c754e2.
کامیت 35c33fa93 این فایلِ ازپیشاجراشده را درجا ویرایش کرد. بایتهای اصلی
بازگردانده شدهاند؛ expand افزایشی 0112 اصلاح تابع تکمیل را اعمال میکند.
پایگاههای دارای checksum اصلی بهطور عادی ارتقا مییابند و تمام دفتر مهاجرت،
کاربران و تاریخچهٔ انتشارشان حفظ میشود. پایگاه تازه نیز به همان توابع اصلاحشده میرسد.
پایگاه دارای checksum ویرایششدهٔ
185ccb8f53a78c0693813c2c5d2b06e577bccf66ab36b2662b7c71a95cdd23b9
تاریخچهٔ مهاجرت واگرا دارد و همچنان fail-closed میماند. checksum آن را بازنویسی
نکنید، guard را دور نزنید و ساخت پایگاه خالی را تعمیر آن ننامید. backup و باینری
قدیمی متناظر را نگه دارید و تاریخچهٔ اجراشده و تعریف واقعی توابع را فقطخواندنی
بررسی کنید. چنین پایگاهی پیش از ارتقا به این خط، به تطبیق تاریخچهٔ جداگانه با
بازبینی صریح و حفظ داده نیاز دارد. ارتقای عادی نسخهٔ اصلی 0102 مجوز آن تطبیق
نیست و پایگاه پذیرش حفظشده را خودکار تغییر نمیدهد.