راهنمای توسعه‌دهندگان پوشش

افزونه‌های موجود

زیرسامانه‌ی مستقل Versioning

Composition قطعی و بدون حدس

کد داخلی Platform با assembly scanning پیدا نمی‌شود. Host به‌صورت صریح Framework، Platform و Theme را ثبت می‌کند؛ خود Platform نیز فهرست ثابت و مرتب‌شده‌ی registrarها را اجرا می‌کند.

var builder = WebApplication.CreateBuilder(args);

builder.AddServiceDefaults();
builder.AddPoshesh().AddPlatform();
builder.Services.AddDefaultTheme();

var app = builder.Build();

app.UsePoshesh();
app.MapDefaultEndpoints();
app.Run();

Features/Example/
├── Domain/                 # Entity، value object و EF configuration
├── Services/               # command/query service و پیاده‌سازی منطق
├── Controllers/            # endpointهای MVC؛ معمولاً Area ادمین
├── Models/                 # view model، input model و projection
├── Views/                  # Razor viewهای همان قابلیت
├── Permissions.cs          # نام permissionهای پایدار
├── ExamplePermissionProvider.cs
├── ExampleAdminMenuProvider.cs
└── Registrar.cs            # ثبت صریح سرویس‌های این slice

پوشه‌ها می‌توانند بر اساس نیاز feature کمتر یا بیشتر باشند؛ اصل مهم این است که فایل‌های یک قابلیت کنار هم بمانند و برای همکاری با قابلیت دیگر از قرارداد مشترک عبور کنند.

• Feature به Feature ارجاع نمی‌دهد. مثلاً Posts نباید namespace یا entity مربوط به Taxonomy را مستقیماً مصرف کند.
• همکاری بین featureها از Framework می‌گذرد. قرارداد، event، registry یا سرویس feature-neutral راه ارتباط است.
• Composition تنها جای شناخت همه‌ی featureهاست. فهرست registrarها در Platform/Composition صریح و مرتب است.
• Host نازک می‌ماند. Host محل business rule، query یا entity جدید نیست.
• Core از جزئیات آزاد است. ASP.NET Core، EF Core و typeهای Platform وارد قراردادهای Core نمی‌شوند.
• DbContext همان Unit of Work است. generic repository و UnitOfWork wrapper عمومی ساخته نمی‌شود.
• شناسه‌ها Guid v7 هستند. entity شناسه را سمت client و پیش از insert می‌سازد.
• Theme فقط قرارداد قابل‌دسترسی خود را می‌بیند. مدلی که قالب عمومی نیاز دارد باید در Framework قرار بگیرد، نه namespace یک feature.

// نادرست: وابستگی مستقیم به slice دیگر
using Poshesh.Platform.Features.Taxonomy.Domain;

// درست: قرارداد feature-neutral در Framework.Core
public sealed class PostService(IContentTaxonomyService taxonomy)
{
    // همکاری از مرز عمومی و پایدار انجام می‌شود.
}

قرارداد عمومی یا primitive

Framework.Core؛ فقط وقتی چند مصرف‌کننده به یک مرز پایدار نیاز دارند.

پیاده‌سازی مشترک غیر وب

Framework.Infrastructure؛ مانند cache، storage، background job یا convention دیتابیس.

رفتار عمومی MVC/HTTP

Framework.Web؛ مانند middleware، TagHelper، theme/plugin glue یا asset resolver.

قابلیت پایه‌ی خود CMS

یک slice در Platform/Features/{Name} و ثبت صریح registrar آن در composition.

قابلیت اختیاری یا پروژه‌ای

یک پروژه در plugins/؛ اگر داده دارد با DbContext و migration مستقل.

تغییر ظاهر سایت عمومی

در themes/: یک پروژه‌ی قالب بسازید یا ویوی موردنظر را در قالب فعال override کنید (docs/themes.md).

تنظیم startup یا میزبانی

Poshesh.Web؛ فقط composition و configuration، نه business logic.

ابزار انتشار/نگهداری مستقل

tools/ یا زیرسامانه‌ای با مرز استقرار روشن؛ ساخت پروژه‌ی تازه باید تصمیم معماری باشد.

cd D:\Github.com\YektaBrick
pwsh -File .\eng\publish.ps1

اگر ExecutionPolicy جلوی اجرای اسکریپت را گرفت، فقط برای همین پردازش از دستور زیر استفاده کنید:

pwsh -ExecutionPolicy Bypass -File .\eng\publish.ps1

نمونه‌های کاربردی

.\eng\publish.ps1                         # همه خروجی‌ها با نسخه فعلی
.\eng\publish.ps1 -Version 1.0.0          # ثبت نسخه هسته و ساخت همه خروجی‌ها
.\eng\publish.ps1 -Target App             # فقط سایت، Updater و ZIP هسته
.\eng\publish.ps1 -Target Plugins         # همه افزونه‌های دارای plugin.json
.\eng\publish.ps1 -Target Themes -NoZip   # فقط پوشه قالب‌ها، بدون ZIP

Published/
├── App/                              # سایت دقیقاً به شکل قابل کپی روی سرور
│   ├── Poshesh.Web.exe
│   ├── version.json
│   ├── wwwroot/
│   └── updater/
│       └── Poshesh.Updater.exe       # برای update و restart الزامی
├── poshesh-1.0.0.zip                 # بسته قابل انتشار هسته
├── Plugins/
│   ├── projects/                     # پوشه آماده نصب؛ plugin.json در ریشه
│   └── projects-1.0.0.zip            # ZIP قابل آپلود در مخزن
└── Themes/
    ├── Sample/                       # قالب پوشه‌ای آماده؛ theme.json در ریشه
    └── Sample-1.0.0.zip              # ZIP قابل آپلود در مخزن

• App یک server drop است. محتویات آن بدون ساخت دوباره روی سرور قرار می‌گیرد.
• ZIP هسته manifest دارد. manifest.json فقط داخل آرشیو است و داخل App قرار نمی‌گیرد.
• ZIP افزونه و قالب در ریشه manifest دارند. پوشه‌ی wrapper اضافه ساخته نمی‌شود.
• Default Theme جداگانه منتشر نمی‌شود. قالب RCL پیش‌فرض در خروجی هسته‌ی سایت کامپایل شده است.
• فایل‌های محلی حذف شده‌اند. appsettings.Local.json، appsettings.Development.json و PDB نباید در خروجی مشتری باشند.

1. ابتدا VSC را آماده کنید. سرویس Versioning باید با storage دائمی، دیتابیس و چهار کلید production بالا آمده باشد.
2. اثر انگشت را کنترل کنید. پاسخ GET /api/public/info باید fingerprint مورد انتظار production را برگرداند.
3. پس از تأیید VSC خروجی سایت را بسازید. برای نسخه‌ی مقصد، publish.ps1 -Version x.y.z -Target App را اجرا کنید.
4. محتویات Published/App را به app root سرور منتقل کنید. وجود updater/Poshesh.Updater.exe را جداگانه بررسی کنید.
5. برنامه را اجرا و Installer را کامل کنید. Installer اتصال دیتابیس، ثبت VSC و مدیر اولیه را انجام و appsettings.Local.json مخصوص همان سرور را می‌سازد.
6. ورود و نسخه را بررسی کنید. صفحه‌ی عمومی، پنل ادمین و شماره نسخه‌ی نصب‌شده باید بدون خطا پاسخ دهند.

5ABA6781481EABF9DF92E148921BCB78A75D1A901DB4DAA80200861DC7B00D8B

.\eng\publish.ps1 -Version 1.2.0 -Target App
git diff -- src\Host\Poshesh.Web\version.json

چه کاری کجا انجام می‌شود

مراحل داخل پنل تحت وب

1. خروجی را با publish.ps1 -Version بسازید و تغییر version.json را commit کنید.
2. وارد پنل شوید و به صفحه‌ی «نسخه‌های سایت اصلی» بروید؛ «انتخاب ZIP و انتشار سایت» را بزنید.
3. محصول را poshesh، نسخه را دقیقاً برابر version.json و کانال را stable یا beta بگذارید.
4. فایل Published/poshesh-{version}.zip را انتخاب و توضیحات نسخه را کوتاه و کاربردی بنویسید.
5. «بارگذاری و ثبت» را بزنید. پیام موفقیت تعداد فایل‌ها و تعداد فایل‌های حذف‌شده را گزارش می‌کند؛ همین عدد را کنترل کنید.
6. در فهرست نسخه‌ها، وجود فایل بسته، کانال و وضعیت فعال را بررسی کنید. دکمه‌ی «محتوای بسته» فهرست فایل‌ها و حذف‌شده‌ها را نشان می‌دهد.

اعمال نسخه روی سایت

پس از فعال‌شدن release، مدیر سایت می‌تواند از /admin/system/update به‌روزرسانی را شروع کند. اپراتور مرکزی نیز در صفحه‌ی «سایت‌های نصب‌شده» یک سایت را انتخاب و «بروزرسانی از راه دور» را می‌زند؛ چند لحظه بعد «بررسی زنده» وضعیت بازگشت سایت را تأیید می‌کند.

1. در plugin.json مقدارهای id و version را بررسی کنید. شناسه باید lower-case و با نام package و پوشه‌ی نصب دقیقاً یکسان باشد.
2. مطمئن شوید entryAssembly یا DLL پیش‌فرض افزونه در خروجی وجود خواهد داشت و dependencyها درست‌اند.
3. دستور زیر را اجرا و ZIP همان نسخه را از summary نهایی بردارید.

.\eng\publish.ps1 -Target Plugins

# خروجی نمونه
Published\Plugins\projects\
Published\Plugins\projects-1.0.0.zip

انتشار از پنل تحت وب

1. وارد «مخزن افزونه و قالب» شوید.
2. اگر package هنوز وجود ندارد، «تعریف بسته و آپلود» را بزنید؛ نوع افزونه، شناسه‌ی canonical، نام، توضیح، دسته، حداقل پلن و وضعیت Listed/Featured را تعیین کنید. می‌توانید ZIP اولین نسخه را همان‌جا بدهید.
3. اگر package قبلاً تعریف شده، آن را انتخاب و «نسخه جدید» را بزنید؛ مسیر دیگر «نسخه‌ها» → «انتشار نسخه جدید» است.
4. شماره نسخه باید دقیقاً با plugin.json:version برابر باشد. کانال، توضیحات و ZIP ساخته‌شده را انتخاب و «آپلود و انتشار» را اجرا کنید.
5. سرویس ساختار ZIP، identity، نسخه، dependency، entry assembly و محدودیت‌ها را بررسی می‌کند؛ سپس archive را hash و امضا و seal فایل‌های افزونه را داخل بسته ثبت می‌کند.

یک قالب می‌تواند تمام امکانات زیرساخت را داشته باشد: کنترلر، ViewComponent، ویجت صفحه‌ساز، سرویس، کلاس تنظیمات، دسترسی، منوی پنل، Job، حتی DbContext و migration خودش، و قلاب‌ها (Event / Filter / Slot). قرارداد طراحی این است که قابلیت‌های قابل‌استفاده‌ی مجدد در افزونه ساخته شوند تا با تعویض قالب از بین نروند؛ اما اگر بخواهید، همه‌چیز می‌تواند داخل قالب باشد.

ساختار پروژه

themes/Poshesh.Theme.Default/
├── theme.json                    # شناسه، نسخه، parent، dependencies، entryAssembly
├── screenshot.svg                # تصویر پیش‌نمایش در مدیر قالب
├── DefaultTheme.cs               # ITheme + IThemeStartup — نقطه‌ی ورود
├── Themes/default/Views/         # درخت ویوها؛ {id} باید با theme.json یکی باشد
│   ├── Shared/_Layout.cshtml
│   ├── Shared/Error404.cshtml
│   ├── Widgets/{name}/Default.cshtml
│   └── Shared/Components/{Component}/Default.cshtml
├── Features/{Feature}/           # کنترلر و ویوهای خودِ قالب (پنل ادمین)
├── Settings/                     # کلاس‌های ISettings
├── Services/                     # سرویس‌های قالب
├── Widgets/                      # ویجت‌ها + IWidgetProvider
├── ViewComponents/
├── Extensibility/                # Event / Filter / Slot — خودکار کشف می‌شوند
├── Data/                         # اختیاری: DbContext و migration
├── Translations/*.json
└── wwwroot/                      # روی /_content/Theme.{id} سرو می‌شود

نقطه‌ی ورود

public sealed class DefaultTheme : ITheme, IThemeStartup
{
    public void ConfigureServices(IServiceCollection services, IConfiguration configuration)
    {
        services.AddSingleton<INavMenuLocationProvider, DefaultThemeNavLocationProvider>();
        services.AddSingleton<IWidgetProvider, DefaultThemeWidgetProvider>();
        services.AddScoped<DefaultThemeOptionsAccessor>();
        services.AddPosheshTranslations(typeof(DefaultTheme).Assembly);
    }
}

سطح ConfigureServices دقیقاً همان سطح افزونه است. قلاب‌ها نیازی به ثبت دستی ندارند: لودر خودش AddPosheshHooks را روی اسمبلی قالب صدا می‌زند.

بازنویسی ویوها — کاری که فقط قالب می‌تواند بکند

expander برای قالب فعال و سپس هر والد، این مسیرها را جلوتر از همه قرار می‌دهد:

/Themes/{id}/Views/Shared/Components/{Component}/{View}.cshtml
/Themes/{id}/Views/{Controller}/{Action}.cshtml
/Themes/{id}/Views/Shared/{View}.cshtml

هر چیزی که از موتور ویو عبور کند قابل جایگزینی است: ویوی یک feature هسته، markup یک ویجت، ViewComponent یک افزونه، layout، partial و صفحه‌ی خطا. دو استثنای عمدی: پنل ادمین پوسته‌ی ثابت خود را نگه می‌دارد، و ویویی که با مسیر صریح ~/… رندر شود از expander عبور نمی‌کند.

1. در theme.json شناسه‌ی canonical (lower-case)، نسخه، parent، dependencies و entryAssembly را کنترل کنید.
2. پوشه‌ی ویوها باید Themes/{id}/Views باشد و {id} دقیقاً برابر شناسه‌ی manifest؛ مسیر ویوی کامپایل‌شده همین است و expander با همین مطابقت می‌دهد.
3. Host نباید به پروژه‌ی قالب ProjectReference داشته باشد؛ در آن صورت قالب دوبار بارگذاری می‌شود و کنترلرهایش AmbiguousMatchException می‌دهند.
4. دستور زیر را اجرا کنید:

.\eng\publish.ps1 -Target Themes

# خروجی یک قالب با شناسه canonical برابر default
Published\Themes\default\            # پوشه‌ی آماده‌ی انتشار (theme.json در ریشه)
Published\Themes\default-1.0.0.zip   # بسته‌ی قابل آپلود
Published\App\themes\default\        # همان قالب، پیش‌نصب در خروجی سرور

انتشار از پنل تحت وب

1. در «مخزن افزونه و قالب»، برای package جدید «تعریف بسته و آپلود» و نوع قالب را انتخاب کنید.
2. شناسه‌ی package باید دقیقاً با theme.json:id و نام پوشه‌ی نصب برابر باشد.
3. برای نسخه‌های بعدی package را انتخاب و «نسخه جدید» را بزنید؛ version، channel، notes و ZIP قالب را وارد کنید.
4. پس از انتشار، وضعیت Active و Listed را جداگانه کنترل کنید. سرویس manifest، parent/dependency، نسخه و ساختار archive را اعتبارسنجی و بسته را امضا می‌کند.

خطاهای رایج

1. در «برگه‌ها ← هدر و فوتر» (/admin/layouts) یک مورد جدید بسازید و نوع آن را هدر یا فوتر بگذارید.
2. پس از ذخیره، مستقیم وارد صفحه‌ساز می‌شوید و آن را مثل هر صفحهٔ دیگری می‌چینید.
3. در «تنظیمات ← قالب و لایه‌بندی» آن را به‌عنوان هدر یا فوتر پیش‌فرض سایت انتخاب کنید.
4. در هر برگه یا مطلب، در صورت نیاز، همان انتخاب را برای آن صفحه بازنویسی کنید.

در فرم برگه و مطلب — و در تب «برگه» داخل صفحه‌ساز — برای هرکدام از سربرگ و پاصفحه سه گزینه وجود دارد:

محتوای داخل تگ، طرح پیش‌فرض خودِ قالب است. تا وقتی هدری انتخاب نشده باشد همان رندر می‌شود؛ به‌محض انتخاب، جای آن را می‌گیرد. پس کافی است سربرگی که از قبل داشته‌اید را داخل تگ بگذارید.

<poshesh-header hidden="@blankCanvas">
    <header class="my-theme-header">
        @await Component.InvokeAsync("Menu", new { location = "primary" })
    </header>
</poshesh-header>

<main>@RenderBody()</main>

<poshesh-footer hidden="@blankCanvas">
    <footer class="my-theme-footer">…</footer>
</poshesh-footer>

ویژگی hidden برای صفحات «بوم خالی» است؛ با true هیچ چارچوبی رندر نمی‌شود. قالبی که اصلاً این تگ را ننویسد، هدر داینامیک نخواهد داشت و این یک انتخاب معتبر است.

قراردادهایی که می‌توانید مصرف یا جایگزین کنید

یک نوع محتوای جدید (مثلاً «محصول» در یک افزونه) با یک خط، همین قابلیت را می‌گیرد؛ لازم نیست چیزی دربارهٔ هدرها بداند:

// پیش از رندر شدن Layout صدا زده می‌شود؛ MVC ابتدا View و سپس Layout را اجرا می‌کند.
contentLayout.SetChoices(
    new SiteLayoutPartChoice(product.HeaderMode, product.HeaderPartId),
    new SiteLayoutPartChoice(product.FooterMode, product.FooterPartId));

بازنویسی ظاهر رندر

خروجی هدر از یک ViewComponent قابل بازنویسی می‌آید. برای تغییر مارک‌آپ آن، این فایل را در قالب خود بسازید:

themes/{Name}/Views/PageBuilder/LayoutPart/Default.cshtml

صفحهٔ مطالب دقیقاً مدل وردپرس است: نشانی آن برگه آرشیو مطالب را نشان می‌دهد، عنوان و نشانی از خودِ برگه گرفته می‌شود و محتوای برگه نمایش داده نمی‌شود. مسیر /posts هم به کار خود ادامه می‌دهد.

عرضهٔ یک فهرست تازه از افزونه

هر ماژول می‌تواند فهرست خودش را به‌عنوان گزینهٔ صفحه اصلی عرضه کند. کافی است یک IFrontPageSource ثبت شود؛ نه مسیریابی تغییر می‌کند و نه صفحهٔ تنظیمات.

internal sealed class ShopLandingFrontPageSource(ProductQueries products) : IFrontPageSource
{
    public string Key => "shop.landing";

    public string DisplayName => "صفحهٔ فرود فروشگاه";

    public async Task<ContentRenderResult?> BuildAsync(
        FrontPageRenderContext context,
        CancellationToken cancellationToken = default)
    {
        var model = await products.BuildLandingAsync(context.CanonicalPath, cancellationToken);
        return new ContentRenderResult(
            "ShopLanding",
            model,
            new ContentCacheProfile(true, ["shop:products", "site:metadata"]));
    }
}

// در Registrar افزونه:
services.AddScoped<IFrontPageSource, ShopLandingFrontPageSource>();

FrontPageRenderContext دو چیز می‌گوید: عنوانی که باید جایگزین عنوان پیش‌فرض شود (وقتی فهرست، میزبان یک برگه است) و نشانی‌ای که در آن سرو می‌شود — برای canonical و لینک‌های صفحه‌بندی.

صفحه‌ساز سه حالت دارد: page، block و layout. حالت layout برای هدر و فوتر است و مثل بلوک رفتار می‌کند — بدون دکمهٔ انتشار، بدون تب تنظیمات برگه، و بدون امکان درج بلوک تودرتو.

چه چیزی بوم را تازه می‌کند

تغییرات داخل درخت ویجت‌ها به‌صورت قطعه‌ای به بوم تزریق می‌شوند. اما هر چیزی که سرور رندر می‌کند — چارچوب صفحه، توکن‌های طراحی، بوم خالی — بیرون از آن درخت است و بارگذاری دوبارهٔ بوم لازم دارد. این موارد آن را اجرا می‌کنند:

• ذخیرهٔ «تنظیمات سایت» (رنگ‌ها، تایپوگرافی، عرض کانتینر، CSS سراسری)
• ذخیرهٔ «تنظیمات برگه»، از جمله تغییر هدر یا فوتر همان برگه
• انتشار یا لغو انتشار از داخل پنل برگه
• دکمهٔ «نوسازی بوم» در نوار بالا، برای وقتی که چیزی را بیرون از این ویرایشگر عوض کرده‌اید

نوارهای بالای صفحه

برای دیدن راهنمای خودِ فرایند، روی فضای خالی بوم کلیک کنید. پنل تنظیمات، ورودی‌های آماده مانند returnUrl و نتیجه‌های قابل قبول برای گام «پایان» را نشان می‌دهد.

1. گام مبدأ را پیدا کنید و خروجی درست را بخوانید؛ برای مثال «ساخته شد»، «در انتظار تأیید» یا «ناموفق».
2. از نقطهٔ همان خروجی بکشید. یک خط موقت همراه نشانگر ظاهر می‌شود.
3. روی ورودی سمت راست یا هرجای بدنهٔ مقصد مکث کنید تا مقصد برجسته شود.
4. دکمهٔ ماوس را رها کنید. مسیر منحنی با پیکان ساخته می‌شود و بررسی خودکار اجرا می‌گردد.

هر خروجی فقط یک مقصد دارد. اگر همان خروجی را دوباره وصل کنید، اتصال قبلی با مقصد جدید جایگزین می‌شود. برای فرستادن اجرا به دو مسیر متفاوت، باید از دو خروجی جدا مانند «درست/نادرست» استفاده کنید؛ یک خروجی عادی به‌صورت هم‌زمان دو مقصد ندارد.

چند نمونهٔ خواندن مقدار

{{form.mobile}}
{{form.firstName}} عزیز، خوش آمدید
{{lookup.label}}
/my?return={{returnUrl}}

اگر کل فیلد فقط یک توکن باشد، مقدار اصلی آن ــ حتی عدد، بله/خیر یا شیء JSON ــ حفظ می‌شود. اگر توکن داخل یک جمله باشد، مقدار به متن تبدیل و در همان جای جمله قرار می‌گیرد. برای جلوگیری از غلط تایپی، از فهرست «درج متغیر…» کنار فیلد استفاده کنید.

مدیریت متغیرهای فرایند

1. در نوار بوم روی دکمهٔ { } کلیک کنید؛ عدد کنار آن تعداد متغیرهای اعلام‌شده را نشان می‌دهد.
2. «افزودن متغیر» را بزنید و یک نام فنی مانند profile.segment و یک عنوان قابل فهم بنویسید.
3. نوع را از متن، عدد، بله/خیر، تاریخ‌وزمان یا دادهٔ JSON انتخاب کنید و در صورت نیاز مقدار اولیه بدهید.
4. تعداد استفاده‌ها کنار هر متغیر دیده می‌شود. تغییر نام، ارجاع‌های شناخته‌شده را نیز بازنویسی می‌کند؛ حذف، ارجاع‌های باقی‌مانده را برای اصلاح مشخص نگه می‌دارد.

خطا با هشدار چه تفاوتی دارد؟

خطا یعنی نمودار از نظر ساختاری قابل اجرا نیست؛ مانند نبودن شروع، ابزار ناشناخته یا اتصال به گام حذف‌شده. انتشار تا رفع آن ممکن نیست. هشدار دربارهٔ ریسک یا مسیر ناقص است؛ مانند گام دور از دسترس یا خروجی باز. هشدار جلوی انتشار را نمی‌گیرد، اما باید آگاهانه پذیرفته شود.

اجرای آزمایشی را چگونه بخوانیم؟

1. روی «آزمایش» کلیک کنید. ورودی پیشنهادی بر اساس متغیرهای فرایند ساخته می‌شود؛ آن را به شکل یک شیء JSON ویرایش کنید.
2. «شروع آزمایش» را بزنید. متن ورودی نباید بیشتر از ۶۴ کیلوبایت باشد و باید با { } شروع و پایان یابد.
3. خلاصه، وضعیت، تعداد گام‌ها، زمان کل و کندترین گام را بررسی کنید.
4. در Timeline روی هر ردیف کلیک کنید یا با قبلی/بعدی حرکت کنید؛ همان گام روی بوم پیدا و برجسته می‌شود.
5. متغیرهای خروجی را باز کنید. مقدارهای حساس پوشانده شده‌اند و نباید برای رفع اشکال آشکار شوند.

{
  "returnUrl": "/my"
}

انتخاب و چیدمان گروهی

ساخت و استفاده از Fragment

1. گام‌های یک الگوی تکراری ــ مانند «تأیید موبایل و مسیر خطا» ــ را انتخاب کنید.
2. از نوار بالا «ابزارهای حرفه‌ای» را باز، نامی روشن وارد و «ذخیرهٔ انتخاب» را بزنید.
3. در نمودار سازگار بعدی، همان پنجره را باز و «درج روی بوم» را انتخاب کنید. متغیرهای لازم که هنوز وجود ندارند نیز افزوده می‌شوند.

خواندن صفحهٔ اجراها

جزئیات هر اجرا، نسخهٔ ورک‌فلو، زمان شروع و پایان، گام فعلی، نتیجه و تاریخچهٔ گام‌ها را با مدت هر مرحله نشان می‌دهد. برای حفاظت از اطلاعات شخصی، متغیرهای کامل اجرا در این صفحه نمایش داده نمی‌شوند. اگر گام دارای اثر بیرونی باشد، بخش «عملیات‌های پس‌زمینه» وضعیت در انتظار، در حال ارسال، ارسال‌شده یا ناموفق، تعداد تلاش و آخرین خطا را جدا نشان می‌دهد.

سطوح دسترسی پیشنهادی

خطاهای رایج و راه‌حل سریع

• هر خروجی مهم به مقصد روشن متصل است و هر مسیر به «پایان» می‌رسد.
• هیچ خطای ساختاری باقی نمانده و هشدارها آگاهانه بررسی شده‌اند.
• متغیرهای محرمانه حساس‌اند و یادداشت‌ها حاوی رمز یا کد نیستند.
• آزمایش Timeline قابل انتظار دارد و گام کند یا مسیر اشتباه دیده نمی‌شود.
• پس از انتشار، صفحهٔ واقعی در حالت ناشناس و با یک دادهٔ کنترل‌شده آزمایش شده است.
• در اجرای واقعی، نتیجه و وضعیت عملیات‌های پس‌زمینه از بخش «اجراها» کنترل شده است.