بازیابی و بازگردانی#

بازیابی در الامر یعنی ادامه‌دادن از روی شواهد ثبت‌شده، نه ساختن یا بازپخش وضعیت. CLI نقاط checkpoint غیرمحرمانه را محلی ثبت می‌کند، Registry وضعیت معتبر انتشار را نگه می‌دارد و human gateها تصمیم خود را همراه چکیده ثبت می‌کنند. این صفحه قالب‌های checkpoint، قراردادهای resume و راه امن بازگشت از هر وضعیت شکست را گرد می‌آورد.

checkpointهای محلی که CLI ثبت می‌کند#

CLI پیوند غیرمحرمانهٔ پروژه یعنی .al-amr/project.json را با مبدأ Registry، projectId و شناسه‌های آخرین target و submission می‌نویسد. این شناسه‌ها را پیش از ادامه محلی ثبت می‌کند تا فرمان قطع‌شده بتواند وضعیت سرور را ببیند و به‌جای شروع از نو، از آن استفاده کند. این فایل‌ها هیچ اعتبارنامه‌ای ندارند و commit‌شدنشان امن است.

alamr status --json --non-interactive همیشه نخستین خواندن پس از قطع‌شدن است: چک‌پوینت محلی را با وضعیت معتبر Registry تطبیق می‌دهد.

بازیابی یک تست bundle#

frontendهای Environment و App از تست تک‌مرحله‌ای bundle نگه‌داری‌شده در Registry استفاده می‌کنند. frontend میزبانی‌شده نزد ناشر، handshake مسیر well-known یا handoff نوع test prepare/resume برای بازسازی وجود ندارد:

# Environment
alamr build --json
alamr test --bundle dist --json --visibility unlisted --channel preview

# App
alamr build --json
alamr test --yes --json

# Plugin
alamr test --json --visibility unlisted --channel preview

• بازیابی را با alamr status --json --non-interactive آغاز کنید و target، submission، snapshot digest و artifact integrity بازگشتی را نگه دارید.
• اگر بایت‌های build تغییر نکرده‌اند، همان فرمان محصول‌ویژهٔ test را دوباره اجرا کنید. CLI فقط target و submission دقیقاً منطبق را بازاستفاده می‌کند.
• اگر بایت‌های Environment تغییر کرده‌اند، entry.version را بالا ببرید، دوباره build بگیرید و bundle را تست کنید. اگر بایت‌های App تغییر کرده‌اند، دوباره build و test کنید؛ نسل build جدید revision تغییرناپذیر تازه‌ای می‌گیرد.
• Plugin فقط وقتی version خود را نگه می‌دارد که manifest و بایت‌های package همچنان منطبق باشند. بایت‌های تغییریافتهٔ Plugin به SemVer تازه نیاز دارند. deploymentهای بک‌اند HTTPS/WSS میزبانی‌شده نزد ناشر، targetهای جداگانه و بررسی‌شده باقی می‌مانند.

ادامهٔ handoff ورود device#

وقتی عامل یا محیط بدون مرورگر به نشست حساب انسانی نیاز دارد، CLI به‌جای خودکارسازی مرورگر از handoff ساختاریافتهٔ device استفاده می‌کند:

alamr login --device --json
# Human opens verificationUriComplete and confirms userCode.
alamr login --resume <handoffId> --registry <origin> --json

فرمان اول یک سند JSON برمی‌گرداند و OAuth device code را هرگز آشکار نمی‌کند. اجرا روی ALAMR_LOGIN_APPROVAL_REQUIRED مکث می‌کند؛ پس از تأیید انسان، همان فرمان resume دقیق ورود را کامل می‌کند. ALAMR_LOGIN_APPROVAL_PENDING یعنی انسان هنوز تأیید نکرده است: به اندازهٔ retryAfterSeconds بازگشتی صبر کنید و همان فرمان resume را دوباره اجرا کنید. handoff گم‌شده یا منقضی قابل بازیابی نیست — جریان device تازه شروع کنید؛ فایل pending را هرگز بازسازی نکنید.

human gateهای گردش‌کار عامل#

اتوماسیون مبتنی بر Journey در هر human gate اعلام‌شده متوقف می‌شود. هر gate عامل خود (human_owner، human_reviewer یا platform_admin)، تصمیم مورد انتظار (approve، reject یا attest)، شواهد لازم و انقضای اختیاری بین ۶۰ تا ۸۶۴۰۰ ثانیه را مشخص می‌کند. اجراکنندهٔ workflow تا وقتی gate در انتظار است ALAMR_WORKFLOW_APPROVAL_REQUIRED و پس از ثبت تصمیم ALAMR_WORKFLOW_APPROVED را گزارش می‌دهد.

resume فقط پس از تصمیم ثبت‌شدهٔ gate معتبر است و باید با همان عامل، مقصد، نسخهٔ ثابت و چکیدهٔ شواهد دقیقی باشد که gate اعلام کرده است. عامل هرگز نباید تصمیم بسازد، mutation را بازپخش کند یا بر اساس اسکرین‌شات یا متن از gate عبور کند. بازپخش idempotent یک workflow تکمیل‌شده به‌جای تکرار اثرات جانبی، ALAMR_WORKFLOW_IDEMPOTENT_REPLAY را برمی‌گرداند.

بازیابی بر اساس وضعیت انتشار#

وضعیت یا نشانه فعلی	بازیابی امن
draft	دوباره build بگیرید و check تک‌مرحله‌ای محصول را اجرا کنید: برای Environment فرمان alamr test --bundle dist، برای App فرمان alamr test و برای Plugin فرمان alamr test. اگر target اشتباه است، به‌جای ویرایش شواهد ثابت revision یا version تازه بسازید
checks_running	alamr status --json را بخوانید و منتظر عملیات فعلی بمانید. شروع بررسی تکراری تعارض می‌دهد
checks_failed	همهٔ checkهای ساختاریافته را بخوانید و مشکل bundle محلی یا deployment را رفع کنید. اگر بایت‌ها تغییر کردند دوباره build بگیرید، سپس همان alamr test محصول‌ویژه را تکرار کنید؛ CLI فقط target دقیقاً منطبق را بازاستفاده و checkها را درجا تکرار می‌کند
ready_for_review	alamr publish را یک‌بار اجرا کنید. برای دانستن وضعیت مرجع از status استفاده کنید
in_review	منتظر بازبین مستقل بمانید. مالک Project یا ارسال‌کننده حتی با اختیار مدیر هم نمی‌تواند تأیید کند؛ توکن Project نیز نمی‌تواند بازبینی کند
rejected	این گذار نهایی است. Registry فقط وقتی می‌تواند همان درخواست ردشده را به draft برگرداند که مقصد و مجموعهٔ بستهٔ ثابت دقیقاً همان باشند. اگر کد، مانیفست، پیکربندی Environment یا استقرار تغییر کرد، مقصد تازه بسازید؛ Plugin به SemVer تازه نیاز دارد
withdrawn	مقصد و درخواست تازه بسازید؛ شواهد پس‌گرفته‌شده را ویرایش نکنید
approved	منتظر گذار مدیریتی published توسط مدیر پلتفرم دیگری بمانید. اگر مجموعهٔ بسته عوض شده باشد، انتشار fail-closed می‌شود
published	برای تغییر، بازبینی یا نسخهٔ تازه منتشر کنید. برای برگشت به محتوای سالم قبلی، به مقصد واجد شرایط هنوز منتشرشده بازگردانی کنید
yanked یا suspended	این وضعیت‌ها با گذار دوباره فعال نمی‌شوند. مقصد تازه‌ای منتشر کنید یا به مقصد published دیگری بازگردید
تعارض چکیدهٔ نسخهٔ ثابت یا بسته	متوقف شوید. شناسهٔ مقصد و مجموعهٔ بسته را بررسی کنید. چکیده را بازنویسی نکنید؛ در صورت تغییر واقعی محتوا مقصد تغییرناپذیر تازه بسازید

اثرهای پس‌گرفتن و تعلیق#

yanked و suspended هر دو گذار مدیریتی و نهایی از published هستند. گذار دلیل می‌خواهد و در گزارش ممیزی ثبت می‌شود.

• برای revision یک Environment، Registry آن را به‌عنوان bundle نگه‌داری‌شدهٔ فعال کنار می‌گذارد و sessionهای Runtime و Grantهای Plugin مرتبط را باطل می‌کند.
• برای نسخهٔ Plugin، Registry آن را از حالت فعال خارج و Grantهای صادرشدهٔ Plugin برای همان نسخه را باطل می‌کند.
• برای بازبینی استقرار، Registry استقرار را تعلیق و Grantهای Plugin آن را باطل می‌کند.

نسخهٔ ثابت اصلی، رکورد بازبینی و مدرک publishedAt باقی می‌مانند. برای نسخهٔ yankشدهٔ Plugin، قفل‌های integrity قبلی تکرارپذیر می‌مانند، اما alamr add نصب تازهٔ آن نسخه را رد می‌کند.

بازگردانی بدون بازنویسی تاریخ#

بازگردانی اشاره‌گر فعال Project را به مقصدی می‌برد که:

• به همان Project تعلق دارد؛
• هنوز وضعیت published دارد؛
• زیر مسدودسازی اضطراری فعال نیست.

بازگردانی دلیل می‌خواهد و در گزارش ممیزی ثبت می‌شود. مقصد، بازبینی، بسته یا درخواست قبلی را ویرایش نمی‌کند. بازگردانی Environment، bundle نگه‌داری‌شدهٔ revision انتخابی را برمی‌گزیند. برای App، بازگردانی مانند گذار انتشار نهایی و enable سراسری، پیش از تغییر وضعیت اتصال bundle نگه‌داری‌شده را دوباره بررسی می‌کند؛ revisionهای تاریخی App بدون مدرک bundle خواندنی می‌مانند اما نمی‌توانند مقصد بازگردانی باشند.

ابتدا برنامه را بسازید و بررسی کنید، سپس همان برنامهٔ ذخیره‌شدهٔ دقیق را اعمال کنید:

alamr rollback <environment_revision|app_revision|plugin_release> <targetId> --reason <text> --plan

CLI با چکیدهٔ برنامه ALAMR_ROLLBACK_PLAN_READY را برمی‌گرداند؛ اعمال همان برنامهٔ دقیق ALAMR_ROLLBACK_PLAN_APPLIED را برمی‌گرداند. شکست‌های رایج عبارت‌اند از invalid_rollback برای درخواست بدشکل، rollback_target_not_eligible برای مقصدی که منتشرنشده، block‌شده یا متعلق به Project دیگری است، و project_recovery_admin_required وقتی فراخوان اختیار مدیر ندارد. API مستند مدیریت و کنسول همان عملیات Registry را صدا می‌زنند؛ هرگز با ویرایش شناسه، چکیده، مانیفست یا فایل قفل بازگردانی را شبیه‌سازی نکنید.

برای خود ماشین وضعیت چرخهٔ انتشار، برای کدهای خطای حین بازیابی عیب‌یابی و برای تصمیم‌های بازبینی که پیش از رد یا تأیید می‌آیند بازبینی انسانی را بخوانید.