مرجع CLI#

alamr رابط خط فرمان عمومی (CLI) برای پروژه‌های محیط (Environment)، اپ (App) و پلاگین (Plugin) است. نسخهٔ دقیق CLI را فقط از صفحهٔ شروع و Release Set ترفیع‌یافته نصب کنید؛ سپس انسان و عامل از سطح فرمان پایدار یکسان استفاده می‌کنند:

alamr doctor --json

فرمان‌ها#

• alamr create environment [directory] پروژهٔ آغازگر یک محیط را می‌سازد.
• alamr create environment [directory] --with-backend علاوه بر محیط، بک‌اند اختیاریِ متعلق به همان Environment را نیز سیم‌کشی می‌کند.
• alamr create app [directory] پروژهٔ آغازگر یک bundle از App به‌شکل Compact-first و با SDK تعبیه‌شده را می‌سازد. AppHost دسکتاپ بایت‌های bundle نگه‌داری‌شده را باز می‌کند. Workspace را در مانیفست اعلام و از حالت فعلی presentation برای compose استفاده کنید؛ تغییر حالت سند و نشست App را حفظ می‌کند و با host.presentation.changed به App می‌رسد.
• alamr create plugin [directory] پروژهٔ فقط-فرانت‌اند می‌سازد. برای مرورگر به‌همراه سرویس از --kind full-stack --with-backend و برای بستهٔ فقط-سرویس دارای artifact تغییرناپذیر OpenAPI و بدون خروجی مرورگر از --kind backend-only --with-backend استفاده کنید.
• alamr login ترمینال محلیِ انسان را با کد مجوز (Authorization Code) و PKCE S256 احراز هویت می‌کند.
• alamr login --device --json برای عامل کدنویسی یک تحویل ساختاریافتهٔ تأیید می‌سازد و alamr login --resume <handoffId> --json آن را پس از تأیید انسان کامل می‌کند.
• alamr logout ابتدا توکن مدیریت تعاملی ذخیره‌شده را باطل و سپس آن را به‌صورت محلی حذف می‌کند؛ این فرمان مقدار AL_AMR_TOKEN فراهم‌شده از سوی CI را تغییر نمی‌دهد.
• alamr auth status بدون نمایش اعتبارنامه مشخص می‌کند پوسته خارج است، نشست ذخیره‌شده دارد یا از توکن پردازهٔ CI استفاده می‌کند.
• alamr auth session list نشست‌های فعال CLI کاربر را می‌خواند و alamr auth session revoke <sessionId> --yes یک نشست دقیق را باطل می‌کند.
• alamr link [projectId] پوشه را به پروژه‌ای موجود متصل می‌کند یا، اگر شناسه وارد نشده باشد، پروژهٔ متناظر را در رجیستری (Registry) می‌سازد. برای انتقال نسخهٔ کار به Registry دیگر، ابتدا alamr unlink --yes را اجرا کنید؛ این فرمان فقط اشاره‌گر محلی را برمی‌دارد. Plugin تازه می‌تواند publisher.id: "pub_replace_me" را نگه دارد تا Registry آن را به Publisher حسابِ واردشده متصل کند.
• alamr unlink --yes فقط اتصال محلی پروژه را حذف می‌کند و پروژه یا snapshot تغییرناپذیر Registry را پاک نمی‌کند.
• alamr add <publisher/plugin[@version]> یک پلاگین منتشرشده را نصب و قفل می‌کند. --integration frontend-adapter --adapter <id> کد مرورگر و --integration backend-components مجموعهٔ بک‌اند بررسی‌شده را بدون بستهٔ مرورگر انتخاب می‌کند.
• alamr update <publisher/plugin[@version]> پلاگین نصب‌شده را به یک release دقیق و بازبینی‌شده تغییر می‌دهد.
• alamr remove <pluginId|publisher/plugin> نصب manifest، ورودی lock و وابستگی پکیج بدون مصرف‌کنندهٔ دیگر را در یک تراکنش محلی حذف می‌کند.
• alamr sync کل مجموعهٔ مطلوب پلاگین‌ها را در یک تراکنش lockfile v3 مقید به digest حل و reconcile می‌کند. lockهای قدیمی v1/v2 خواندنی‌اند و به نصب frontend-adapter normalize می‌شوند.
• alamr inspect [publisher/plugin] مانیفست محلی یا رکورد کاتالوگ را بررسی می‌کند.
• alamr validate مانیفست‌ها و فایل‌های قفل محلی را اعتبارسنجی می‌کند.
• alamr build اسکریپت build پروژه را با مدیر پکیج پین‌شده اجرا می‌کند و وجود پوشهٔ خروجی استاندارد را می‌سنجد. آن را پس از alamr link اجرا کنید، چون link ممکن است شناسهٔ محلی آغازگر را با شناسهٔ Registry جایگزین کند؛ فقط build پس از link باید بررسی یا منتشر شود.
• alamr run پردازهٔ dev اعلام‌شدهٔ مدیر پکیج را آغاز یا دوباره استفاده می‌کند و readiness، logها، شناسهٔ پردازه و توکن مات توقف را برمی‌گرداند.
• alamr test نامزد تغییرناپذیر را می‌سازد یا دوباره استفاده می‌کند و checks انتشار را در یک عملیات اجرا می‌کند. برای Environment پوشهٔ build را با --bundle <dir> (معمولاً dist) بدهید. برای App ابتدا alamr build و سپس alamr test را اجرا کنید. Plugin مستقیماً از alamr test می‌گذرد.
• alamr publish نامزد بررسی‌شده را برای بازبینی می‌فرستد.
• alamr status وضعیت فعلی پروژهٔ متصل را از رجیستری می‌خواند.
• alamr doctor --profile <bootstrap|project|runtime|publish> فقط بررسی‌های متناسب با همان مرحلهٔ سفر را اجرا می‌کند.
• alamr project list|show وضعیت خصوصی پروژه را می‌خواند و alamr project member list|add|change|remove|transfer عضویت audit‌شدهٔ admin، developer و viewer را در حدود نقش تأییدشدهٔ سرور مدیریت می‌کند.
• alamr token issue|list|revoke اعتبارنامهٔ CI محدود و تاریخ‌دار را مدیریت می‌کند.
• alamr publication list|checks|submit|transition فقط actionهای بازگشتی منبع انتشار را دنبال می‌کند و از متن status ماشین حالت حدس نمی‌زند.
• alamr review list|inspect <submissionId> صف بازبینی مدیر و شواهد ثابت را می‌خواند. review assignment <submissionId> مالک فعلی و نسخه را می‌خواند. review claim|release <submissionId> --assignment-version <n> --yes یک پرونده را اتمیک claim یا آزاد می‌کند. review decide به نسخهٔ تخصیص بازگشتی و هر دو چکیدهٔ ثابت نیاز دارد؛ رد کردن علاوه بر آن --category، --summary و --remediation می‌خواهد. review history|evidence تصمیم‌های بسته و وضعیت صریح تولیدکنندهٔ diff/AI را نشان می‌دهد. review handoff-list|handoff-inspect کارهای انتشار تأییدشده را پیدا می‌کند؛ مدیر دوم handoff-claim و سپس handoff-publish را با نسخهٔ handoff و چکیده‌های دقیق اجرا می‌کند. همهٔ mutationها به --yes نیاز دارند.
• alamr rollback <environment_revision|app_revision|plugin_release> <targetId> با دلیل audit‌شده یک هدف تغییرناپذیر واجدشرایط را فعال می‌کند.
• alamr catalog search <all|environment|app|plugin> [query] فقط کاتالوگ عمومی ناشناس را جست‌وجو می‌کند.
• alamr admin users list [--search <query>] [--cursor <cursor>] و alamr admin users show <userId> دایرکتوری ممیزی‌شدهٔ حساب‌ها را می‌خوانند. alamr admin roles list|create|update|archive، alamr admin roles members <roleId> و alamr admin roles assign|unassign <roleId> <userId> تعریف‌ها و تخصیص‌های رول مدیریت‌شدهٔ پلتفرم را مدیریت می‌کنند. همهٔ عملیات admin به حساب ادمین رجیستری نیاز دارند؛ roles create به --key و --display-name و در صورت نیاز --description و --environment env_a,env_b جدا‌شده با ویرگول می‌گیرد (حذف آن یعنی رول در همهٔ Environmentها اعمال شود). roles update همچنین --scope-all (بازگشت به سراسری) و --expected-updated-at <iso> برای optimistic concurrency می‌پذیرد و roles assign با --environment تخصیص را به زیرمجموعه‌ای از اسکوپ رول محدود می‌کند.
• alamr admin reviewers list فهرست اختیارهای فعال بازبین تفویض‌شده را می‌خواند. alamr admin reviewers grant|revoke <userId> --reason <text> --yes فقط اختیار بازبینی را تغییر می‌دهد، نه دسترسی admin یا Project، و رکورد ممیزی شامل عامل، هدف و دلیل ثبت می‌کند. mutationها از --dry-run پشتیبانی می‌کنند و توکن Project را رد می‌کنند.
• alamr admin apps list revisionهای عمومی فعال و وضعیت دسترسی سراسری Runtime را نشان می‌دهد. alamr admin apps enable|disable <appId> <revisionId> --reason <text> فقط همان revision منتشرشده را تغییر می‌دهد، به ادمین Registry نیاز دارد و audit ثبت می‌کند. در v0.x این دسترسی سراسری است و به Environment محدود نمی‌شود.
• alamr admin hubs list [hubEnvironmentId] [zoneId] موجودی اسلات‌های تألیف‌شدهٔ Hub را می‌خواند (مقدار پیش‌فرض env_hub / sunlit-way است). alamr admin hubs set <hubEnvironmentId> <zoneId> <slotId> <environmentId> --reason <text> اسلات دستی را تخصیص می‌دهد یا جایگزین می‌کند و alamr admin hubs clear <hubEnvironmentId> <zoneId> <slotId> --reason <text> تخصیص آن را حذف می‌کند. mutation به مدیر Registry نیاز دارد، فقط دلیل ۳ تا ۱۰۰۰ نویسه‌ای می‌پذیرد و در عملیات جای‌گذاری در هاب مستند شده است.
• alamr workflow get|plan|status|execute|approve|resume <workflowId> یک DAG نسخه‌دار AgentWorkflow v2 را کشف و اجرا می‌کند.

همهٔ فرمان‌ها --json را می‌پذیرند. فرمان تغییردهنده به --yes نیاز دارد و هرجا preflight امن وجود دارد، --dry-run --json نیز بدون نوشتن state محلی یا Registry پشتیبانی می‌شود. نزدیک‌ترین فایل قفل در پوشهٔ جاری یا یکی از والدها، npm، pnpm، Yarn یا Bun را انتخاب می‌کند؛ بنابراین پروژهٔ داخل زیرپوشهٔ یک monorepo نیز درست تشخیص داده می‌شود. دستیار نباید مدیر پکیج را از نصب‌های سراسری حدس بزند.

پردازهٔ محلی و پروفایل‌های آمادگی#

پروفایل‌های doctor مانع می‌شوند یک scaffold تازه به‌خاطر سرویس یا وابستگی‌ای که هنوز وجود ندارد شکست بخورد. bootstrap نسخهٔ Node و انتخاب مدیر پکیج را بررسی می‌کند. project وابستگی‌های نصب‌شده، manifest و lock را نیز می‌سنجد. runtime رجیستری و health endpoint بک‌اند اعلام‌شدهٔ Environment را اضافه می‌کند و publish دسترسی رجیستری و Project دقیق متصل را بررسی می‌کند.

alamr run بدون ساختن فرمان shell، npm یا pnpm یا Yarn را حل می‌کند، اسکریپت dev اعلام‌شده را آغاز می‌کند و رکورد پایدار پردازه را با اطمینان دوباره به کار می‌گیرد. توقف به توکن مات بازگشتی از فرمان شروع نیاز دارد:

alamr doctor --profile bootstrap --json
alamr doctor --profile project --json
alamr run --json
alamr doctor --profile runtime --json
alamr doctor --profile publish --json
alamr run --stop --run-token <runToken> --json

تست bundle تغییرناپذیر#

frontendهای Environment و App، bundleهای نگه‌داری‌شده در Registry هستند. جریان عمومی تست آن‌ها frontend میزبانی‌شده نزد ناشر، handshake مسیر well-known یا مرحلهٔ جداگانهٔ 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

برای Environment، فرمان test --bundle dist مانیفست را اعتبارسنجی، پوشهٔ build را به‌شکل قطعی بسته‌بندی، وجود index.html و cover اعلام‌شده را الزام، integrity از نوع SHA-512 را محاسبه، revision تغییرناپذیر را ایجاد یا دوباره استفاده، بایت‌ها را upload و checks انتشار را اجرا می‌کند. اگر خروجی dist نیست از --bundle <dir> استفاده کنید.

برای App، alamr build پوشهٔ dist را می‌سازد. alamr test بعدی همان بایت‌ها را inventory، pack، upload، bind و بررسی می‌کند. نسل build تغییریافته revision تغییرناپذیر تازه‌ای می‌گیرد.

Plugin مستقیماً از alamr test می‌گذرد. Plugin از نوع full_stack یا backend_only همچنان می‌تواند deploymentهای بک‌اند HTTPS/WSS جداگانه و بررسی‌شده نزد ناشر را در al-amr.deployments.json اعلام کند؛ تحویل bundle مربوط به بایت‌های frontend محصول است، نه این سرویس‌های زنده.

plan وضعیت مطلوب پلاگین#

manifest محیط منبع وضعیت مطلوب است. add، update، remove و sync ابتدا کل مجموعهٔ releaseهای دقیق Registry و artifactهای Managed Store را حل می‌کنند. --plan یک plan کوتاه‌عمر و مقید به digest را بدون تغییر state پروژه ذخیره می‌کند؛ همان عملیات را با --plan-digest بازگشتی و --yes اعمال کنید. plan کهنه، منقضی، تغییریافته یا دارای تلاش قبلی به‌صورت fail-closed رد می‌شود.

alamr add al-amr/media@<version> --adapter react --config-json '{"directCalls":{"enabled":false}}' --plan --json
alamr add --plan-digest <sha256:plan-digest> --yes --json
alamr sync --plan --json
alamr sync --plan-digest <sha256:plan-digest> --yes --json

--config-json یک شیء JSON حداکثر ۶۴ کیبی‌بایتی می‌پذیرد و پس از اعتبارسنجی schema به پیکربندی تغییرناپذیر متعلق به میزبان تبدیل می‌شود. اعمال plan تغییریافته یک lock v3 با وضعیت pending می‌نویسد و برای نصب‌های فرانت‌اند فرمان دقیق مدیر پکیج تشخیص‌داده‌شده را برمی‌گرداند. آن فرمان را صریح اجرا کنید و سپس با alamr sync --yes --json بایت‌های پکیج نصب‌شده را بررسی و lock را به applied ببرید. هیچ resolution ناتمامی authoritative نیست.

اجرای AgentWorkflow v2#

index عمومی Developer Portal عملیات ساختاریافته، وابستگی‌ها، preconditionها، postconditionها، قلمرو mutation، کدهای پایدار نتیجه و مرزهای تأیید انسانی را منتشر می‌کند. CLI پیش از اجرای adapter مجاز و بدون shell، نشانی و SHA-256 دقیق workflow، نسخهٔ دقیق CLI، مبدأ Registry و Platform Release Set را اعتبارسنجی می‌کند.

alamr workflow get environment.create --json
alamr workflow plan environment.create --json
alamr workflow execute environment.create --idempotency-key <caller-key> --inputs '{"directory":"my-world","package_manager":"pnpm","topology":"standalone"}' --json
alamr workflow status environment.create --resume <resumeToken> --json
alamr workflow approve environment.create --resume <resumeToken> --approval-step <stepId> --yes --json
alamr workflow resume environment.create --resume <resumeToken> --json

execute به idempotency key متعلق به فراخوان نیاز دارد و یک resume token یک‌باره برمی‌گرداند. فقط hash هر دو مقدار زیر .al-amr/workflows/ ذخیره می‌شود. تأیید، قصد انسان را برای یک مرحلهٔ منتظر ثبت می‌کند اما آن را resume نمی‌کند؛ عامل باید resume را جداگانه فراخوانی کند. retry با همان idempotency key به‌جای تکرار mutation، اجرای پایدار موجود را دوباره استفاده می‌کند.

مرز بازبینی انتشار#

بدون flag بازبینی، کشف workflow از /agent/v2/index.json عمومی استفاده می‌کند و فقط Release Set با وضعیت promoted را می‌پذیرد. gate انتشار می‌تواند برای یک مجموعهٔ دقیق catalog_verified یک preview جداافتاده deploy کند و CLI را چنین فراخوانی کند:

alamr workflow execute environment.create \
  --workflow-origin <isolated-preview-origin> \
  --release-verification <releaseSetId> \
  --registry <managed-store-registry-origin> \
  --idempotency-key <caller-key> \
  --inputs '{"directory":"my-world","package_manager":"pnpm","topology":"standalone"}' \
  --json

--release-verification ورودی محافظت‌شدهٔ CI انتشار است، نه راهی برای انتخاب candidate توسط کاربر عادی. این flag شناسهٔ دقیق Release Set می‌خواهد و فقط index با mode برابر release_verification، state برابر catalog_verified و شناسهٔ منطبق را می‌پذیرد. هر fetch بعدی workflow باید همان مبدأ جداافتاده، مبدأ Registry و شناسهٔ بازبینی را به کار ببرد. preview هیچ state خصوصی انتشار دریافت نمی‌کند؛ فرمان‌های Portal تولید تا پایان promotion همچنان فقط مجموعهٔ ترفیع‌یافتهٔ قبلی را تبلیغ می‌کنند.

نتیجهٔ JSON نسخه‌دار#

CLI با --json دقیقاً یک سند JSON در خروجی استاندارد می‌نویسد و راهنمای ورود یا متن انسانی را در خطای استاندارد با آن مخلوط نمی‌کند. پوستهٔ پایدار نسخهٔ ۱ چنین است:

{
  "schemaVersion": "1",
  "command": "validate",
  "ok": true,
  "code": "ALAMR_OK",
  "exitCode": 0,
  "message": "Validation passed.",
  "diagnostics": [],
  "nextActions": [],
  "artifacts": [],
  "data": {},
  "meta": {
    "cliVersion": "0.1.0-alpha.1",
    "elapsedMs": 14
  }
}

code نتیجهٔ نمادین و پایدار خودکارسازی است و exitCode دستهٔ عددی پوسته. diagnostics، nextActions و artifacts همیشه آرایه‌اند؛ data مخصوص همان فرمان است و اگر داده‌ای نباشد حذف می‌شود. در نسخهٔ ۱ می‌توان فیلد سازگار افزود و عامل باید فیلد ناشناخته را نادیده بگیرد.

احراز هویت#

ورود تعاملی روی 127.0.0.1 و یک پورت موقت که سیستم‌عامل انتخاب می‌کند گوش می‌دهد و همان نشانی بازگشت نهایی را بدون تغییر در درخواست مجوز و تبادل توکن به کار می‌برد. scheme، نشانی، مسیر و query ثبت‌شدهٔ http://127.0.0.1/callback دقیق می‌ماند و فقط پورت loopback تغییر می‌کند. رابط خط فرمان بیرون از توسعهٔ محلی، نقطهٔ پایانی کشف با HTTP را رد می‌کند و نقطه‌های پایانی مجوز، توکن و ابطال را به مبدأ دقیق صادرکنندهٔ رجیستری محدود می‌سازد. فرایند کشف هرگز نمی‌تواند توکن حامل ذخیره‌شده را به میزبانی دیگر بفرستد. رابط خط فرمان هیچ‌گاه توکن زمان اجرای یک محیط را به‌عنوان اعتبارنامهٔ مدیریتی ذخیره نمی‌کند. CI باید یک توکن پروژهٔ کوتاه‌عمر و دارای دامنهٔ دسترسی را در AL_AMR_TOKEN قرار دهد.

احراز هویت رابط خط فرمان از SSO مرورگر مستقل است. خروج از هاب (Hub) یا پرتال توسعه‌دهندگان (Developer Portal) اعتبارنامه‌های رابط خط فرمان یا CI را در پس‌زمینه باطل نمی‌کند؛ alamr logout نیز نشست‌های مرورگر را پایان نمی‌دهد.

نشست‌های ذخیره‌شدهٔ CLI جداگانه قابل ابطال‌اند:

alamr auth status --json
alamr auth session list --json
alamr auth session revoke <sessionId> --dry-run --json
alamr auth session revoke <sessionId> --yes --json

ابطال نشست جاری، اعتبارنامهٔ محلی همان نشست را نیز حذف می‌کند. توکن پروژه اعتبارنامهٔ پردازه است، نشست مدیریت CLI نیست و در این فهرست دیده نمی‌شود.

تحویل ورود از عامل به انسان#

عاملی که مالک نشست مرورگر نیست، یک handoff کوتاه‌عمر OAuth Device Authorization می‌سازد:

alamr login --device --json

خروجی JSON به‌تنهایی device flow را انتخاب نمی‌کند؛ عامل باید --device را به‌صورت صریح بفرستد.

نتیجهٔ موفق کد ALAMR_LOGIN_APPROVAL_REQUIRED دارد و verificationUriComplete، userCode، expiresAt، یک handoffId مات و فرمان دقیق resumeCommand را برمی‌گرداند. انسان فقط وقتی تأیید می‌کند که کد مرورگر دقیقاً با userCode عامل یکی باشد. سپس عامل فرمان بازگشتی را اجرا می‌کند:

alamr login --resume <handoffId> --registry <origin> --json

اگر هنوز تأیید نشده باشد، نتیجه exitCode: 3، کد ALAMR_LOGIN_APPROVAL_PENDING و retryAfterSeconds محدود دارد. پس از تأیید، ALAMR_LOGIN_COMPLETE برمی‌گردد و اعتبارنامهٔ مدیریت ذخیره می‌شود. مقدار OAuth device_code هرگز در خروجی CLI نمی‌آید؛ در فایل محلی خصوصی و مقید به رجیستری می‌ماند و پس از موفقیت، رد یا انقضا حذف می‌شود. این مسیر برای مرز تأیید انسانی است، نه CI بدون ناظر.

پیش‌بررسی اعتماد پلاگین#

پکیج frontend پلاگین به‌صورت trusted_library در قلمرو مرورگر Environment اجرا می‌شود؛ permission اعلام‌شده sandbox جاوااسکریپت نیست. بنابراین add و update به adapter صریح و تأیید نیاز دارند. ابتدا همان فرمان دقیق را با --dry-run --json اجرا کنید. نتیجه، تأیید Publisher، وضعیت اعتماد، runtime class، permissionها، افشای مرورگر/شبکه و فایل‌های در آستانهٔ تغییر را نشان می‌دهد. فقط پس از بازبینی با --yes اجرا کنید.

add، update و remove، manifest محیط، lock تغییرناپذیر و تراکنش وابستگی واقعی پکیج را هماهنگ نگه می‌دارند. نصب backend_components آداپتر، بسته یا integrity نمی‌نویسد و package manager را اجرا نمی‌کند. هر pluginId حداکثر یک نصب دارد و نصب frontend_adapter یک release تمام‌پشته، مولفه‌های بک‌اند بررسی‌شدهٔ همان release را هم مجاز می‌کند. unlink فقط .al-amr/project.json را تغییر می‌دهد. هیچ‌یک dependency را خودکار نصب نمی‌کنند؛ نتیجه مدیر پکیج تشخیص‌داده‌شده و فرمان دقیق نصب بعدی را برمی‌گرداند.

برابری مدیریت و actionهای سرور#

سطح گرافیکی «مدیریت» از همان endpointهای این فرمان‌ها استفاده می‌کند:

alamr project show --json
alamr project member list --json
alamr project member transfer proj_example pmbr_target \
  --previous-owner-role admin --reason "Permanent handoff" --yes --json
alamr token list --json
alamr publication list --json

هر پاسخ انتشار allowedActions ویژهٔ درخواست‌کننده دارد. عامل باید یکی از همان actionها را انتخاب کند، هدف تغییرناپذیر و state دقیق from را حفظ کند و وقتی action لازم می‌داند --reason بدهد. action غایب یک مرز مجوز یا lifecycle است، نه دکمهٔ پنهان مخصوص Console که باید دور زده شود.

کدهای خروج پایدار#

• 0: موفقیت
• 1: شکست اعتبارسنجی یا عملیات
• 2: شیوهٔ استفادهٔ نامعتبر
• 3: شکست احراز هویت یا مجوز
• 4: شکست شبکه
• 5: تعارض وضعیت

مصرف‌کنندهٔ ماشینی باید کد خروج و فیلدهای ساختاریافتهٔ --json را مبنا قرار دهد، نه تطبیق متن پیام‌های انسانی را. مرجع API رابط مدیریت مشترک را توضیح می‌دهد.

ساخت Environment دارای بک‌اند

alamr create environment my-world --with-backend علاوه بر محیط، اعلان manifest، درخواست Grant در مرورگر، verifier سمت سرور، CORS محدود و health endpoint را می‌سازد. اجرای alamr doctor --json سلامت این endpoint را همراه manifest و Registry بررسی می‌کند.

نقش‌ها و داده‌های اختصاصی Environment در این بک‌اند نگه‌داری می‌شوند؛ Registry فقط مجوز کوتاه‌عمر و حصار Runtime را صادر می‌کند.