2xBRОГРАНИЧЕНИЯ ↗
PROJECTS / ОГРАНИЧЕНИЯ ЗАПУСКА

Разрешайте конкретный запуск.
Не абстрактную идею.

Этот режим нужен, когда повторяемая работа должна выполняться только в заранее понятной границе. Зафиксируйте допустимый рецепт, лимиты и одноразовое подтверждение для текущего состояния проекта.

Настроить ограничения проекта →
01 / WHENПовторяемый запуск требует явных лимитов или отдельного подтверждения перед выполнением.
02 / РЕЗУЛЬТАТПонятная граница: что разрешено, для какого состояния проекта и на какой один запуск.
03 / BOUNDARYПодтверждение ограничено текущим состоянием, имеет срок действия и не даёт постоянного скрытого разрешения.
Техническая модель guardrails
ПРОЕКТCURRENT STATE→ОГРАНИЧЕНИЯRECIPE + LIMIT→APPROVE10 МИН / ОДНО ИСПОЛЬЗОВАНИЕ→ЗАПУСКЯВНО
ТОЛЬКО ЛОКАЛЬНО0 PLANS0 BINDINGS10 MIN APPROVALPROJECT GUARDRAILS / LOCAL POLICY STORE
01 / GUARDRAIL PLAN

Define the guardrail once.

A PLAN binds one saved FLOW recipe to input limits and an approval rule. It stores configuration only — never project files, filenames or run output.

ALWAYSEvery run needs a fresh, one-use approval.
02 / SAVED PLANS

Reusable project guardrails.

НЕТ saved plans yet. Save a FLOW recipe, then define a plan here.

03 / PROJECT BINDINGS

Apply one plan to a project.

Applying a plan also pins the plan's FLOW recipe to the project, so policy and execution cannot silently drift apart.

НЕТ PROJECTS yet. CREATE PROJECT →
SCOPE-BOUNDApproval is for one exact run state.

The approval digest binds project, plan, recipe and the current project object revisions. Change any of them and a new approval is required.

ONE USEApproval is consumed before execution.

A valid approval expires after ten minutes and is removed before FLOW starts. Failed runs do not silently reuse it.

НЕТ SCHEDULERPolicy is not background automation.

Plans and approvals govern explicit RUN NOW actions. WATCH still requires its own visible, armed session.