Переопределения

Живой прогон тест-плана позволяет инъектировать значения на трёх
независимых уровнях: целиком на план, на один pending-элемент или
на один шаг внутри TCM-кейса. Все три могут быть активны на одном
прогоне; раннер выбирает самое специфичное, когда строит request
шага.

Эта страница — справочник по трём уровням: когда каждый локается, что
побеждает в конфликте и как драйвить их из UI.

Об URL в примерах: все примеры используют localhost:5770 как
адрес Mockarty по умолчанию. Если экземпляр работает на удалённом
сервере, замените localhost:5770 на его реальный адрес.

Связанные страницы: Run View ·
Отчёт о прогоне плана ·
Шаги тест-кейсов ·
Runtime-вид прогона (тест-кейс)

Три уровня одним взглядом

Уровень	Что меняет	Когда можно применить	Переживает rerun элемента?	Переживает rerun плана?
Plan-level — context bag	Все `{{plan.X}}` для всех TCM-кейс-элементов, которые стартуют ПОСЛЕ merge.	Пока прогон в полёте (status = `running` / `paused` / `manual_pending`).	Да — merged context живёт на run-строке.	Только если поставить галочку Preserve overrides на rerun.
Item-level — parameters	Поле `parameters` pending-элемента (VU-count для load, seed corpus для fuzz, execution mode для TCM, и т.д.).	Только пока элемент в статусе `pending`.	Нет — сбрасывается на item rerun, чтобы повторная попытка с новыми параметрами была осознанной.	Нет — plan rerun стартует с шаблона.
Step-level — run-extracts (только TCM)	Одну пару ключ/значение на снимке plan-context конкретного case-run.	Пока case-run жив, включая paused / manual_pending.	Harvested extract шага persistится на case-run.	Нет — покрывается сбросом родителя при plan rerun.

Уровни не пересекаются — это независимые слои — но когда раннер
резолвит {{plan.X}} внутри шага, он применяет precedence-правило
ниже.

Plan-level override контекста

«Тип значение в шапке страницы». В шапке Run View есть кнопка
Override context.

Клик открывает drawer, в нём строки с двумя полями:

Key — имя под plan., например auth_token или customer_id.
Value — значение, которое раннер подставит, когда downstream-шаг
напишет {{plan.auth_token}}.

Можно добавить несколько строк; drawer батчит их в одно сохранение,
audit-trail пишет override как единое событие.

Что раннер делает с вашим override

Раннер merge’ит ключи в plan-context bag прогона. Каждый TCM-кейс-
элемент, который стартует ПОСЛЕ merge, видит новое значение при
сборке request’а. Две детали:

Уже бегущий кейс держит свой уже-merged snap. Last-write-wins
на mid-flight шаге слишком опасен — шаг уже резолвил bindings. Но
Run View покажет небольшой баннер на бегущем кейсе: «если перезапустить
step N отсюда — использует новое значение».
Уже завершённые шаги не меняются. Merge действует вперёд,
никогда ретроактивно.

Когда override локается

Plan-level override применим в любое время, пока прогон в полёте.
Раннер откажет (HTTP 409 от endpoint’а, toast «plan run is terminal»
в UI), когда прогон достиг terminal-статуса — passed / failed /
cancelled. Чтобы повторить сценарий завершённого прогона с теми же
значениями, используйте Rerun plan с галочкой
Preserve overrides.

Правила ключей и значений

Ключи должны соответствовать [A-Za-z_][A-Za-z0-9_.]{0,127} —
буквы, цифры, underscore и точка, начинаются с буквы или
underscore, максимум 128 символов. Drawer показывает правило live
при наборе.
Размер строковых значений ограничен; drawer отвергает большие
blob’ы с inline-подсказкой о лимите.
Одно сохранение drawer может содержать десятки ключей —
значительно больше, чем нужно в один push.
Endpoint rate-limited per user (на бешеных кликах вы увидите
«slow down» toast). Бюджет общий с case-step /run-extract из
standalone case-вида.

Item-level override параметров

«Правка параметров pending-элемента до старта». Run View показывает
действие Edit parameters на каждой pending-карточке.

Клик открывает drawer с JSON-редактором, заполненным текущими
параметрами. Правьте значения, сохраняйте — оркестратор подхватит
новую форму при диспатче.

Что обычно меняют

Тип элемента	Полезные overrides
Functional	Per-item env override (для этой одной коллекции — staging-eu, хотя план в целом гоняется по staging).
Load	`vu` (virtual users), `duration`, `targetRps` — сжать дорогой нагрузочный прогон под smoke без правки плана.
Fuzz	`seedCorpus`, `fuzzTimeSec` — кормить tailored-корпус или укоротить бюджет под быстрый re-check.
Chaos	`faultSpec`, `durationSec` — заменить network-latency fault на CPU-throttle для A/B-сравнения.
Contract	`contractVersionId` — закрепить конкретную ревизию контракта для этого diff.
TCM-кейс	`executionMode` — заставить кейс прогнаться в `manual` режиме, хотя план обычно автоматизирует.
Nested plan	(на конверте обычно ничего — дочерний план показывает свои item overrides рекурсивно).

Когда override локается

Item-level override применим только пока элемент в статусе
pending. После старта параметры менять нельзя; оркестратор уже
сделал snapshot. Чтобы очистить или заменить override после прогона
элемента, используйте Rerun item — он сбросит элемент в pending,
после чего параметры можно править снова до следующего диспатча.

Override сбрасывается на rerun (повторная попытка с новыми
параметрами — всегда осознанное действие). Шаблон плана никогда не
изменяется; будущие прогоны того же плана стартуют с сохранённых
параметров.

Step-level override (только TCM)

Это per-step /run-extract flow внутри TCM-кейса — подробно на
Шагах тест-кейсов §5.
Коротко:

Откройте TCM-элемент в Run View; flow-tree кейса — inline.
Клик по шагу → открывается его drawer.
В drawer’е есть кнопка Add extract, в которой пишется одна
пара plan.X = value, scope’нутая на этот case-run.

Step-level override живёт на tcm_case_step_runs и сбрасывается на
step rerun. Он не пропагейтит вверх к родительскому плану; остаётся
внутри кейса. Чтобы значение было видно другим элементам плана,
поднимите его через plan-level drawer.

Precedence — что побеждает

Когда шаг строит request и встречает ссылку {{plan.X}}, раннер
выбирает самое специфичное значение. Порядок, от самого специфичного
к наименее:

case-step run-extract
> case-author default в plan_context_snap
> plan-level run override
> пусто (подстановка не удалась — раннер логирует missing-binding warning)

Для precedence окружения / секретов внутри шага см.
Шаги тест-кейсов §4.

Разбор примера

Прогон плана с auth_token = "T0", установленным через plan-
level drawer.

Стартует Case A. Его первый шаг — Login, который извлекает
auth_token из login-ответа в plan.auth_token. С момента
extract значение становится T1 для оставшейся части Case A —
step-level extract побеждает.
Поздний шаг Case A GET /me использует {{plan.auth_token}} —
получает T1.
Case B стартует ПОСЛЕ завершения Case A. Case B сам не извлекает
auth_token. Его первый шаг видит T0 (plan-level override,
потому что внутри Case B пока никакой step-level extract его не
перезаписал).
Пользователь открывает drawer и пишет auth_token = "T2". Case A
уже terminal — там ничего не меняется. Case C, стартующий после
сохранения drawer, видит T2.

UI walkthrough

[Override surfaces — три drawer — screenshot pending]

Plan-level drawer — кнопка Override context в шапке Run
View. Открывает список строк ключ/значение; save коммитит все
строки сразу.
Item-level drawer — действие Edit parameters на любой
pending-карточке. JSON-редактор; save коммитит новые параметры.
Step-level drawer — клик по шагу внутри развёрнутого TCM-
элемента; в step-drawer’е кнопка Add extract (TCM scope).

Все три auditable: plan-level и item-level overrides пишут
audit-log строку с run id и актёром, чтобы compliance-ревью видел,
кто что patch’ил и когда. Step-level extracts фиксируются на case-
run рядом с authoring-extracts, trail полный.

Частые ошибки

«Cannot override — item is running» — после старта параметры
локнуты. Сделайте rerun элемента, чтобы вернуть его в pending,
потом правьте.
«Plan run is terminal» — прогон уже завершился. Используйте
Rerun plan с Preserve overrides.
Новый ключ не читается — ссылки {{plan.foo}} в TCM-кейсе
работают только после старта кейса. Кейсы, стартовавшие до
вашего override, видят старое значение (или ничего); кейсы,
стартующие после — новое. Делайте re-rerun кейса, если нужно
новое значение.
«Invalid key» — ключи начинаются с буквы или underscore,
содержат только [A-Za-z0-9_.], до 128 символов. Drawer покажет
правило, которое не прошло.
«Value too large» — строковые значения ограничены. Подрежьте
или сохраните тяжёлый payload во вложение шага и сошлитесь на URL
вложения.
Rate limited — пер-юзерный бюджет намеренно держится низким,
чтобы audit-trail оставался читаемым. Батчите ключи в одно
сохранение drawer.

Права

Plan-level override: test_plan:write на namespace прогона.
Item-level override: test_plan:write.
Step-level extract: test_plan:write (нижний case-run endpoint
делит тот же gate).
Чтение текущего лога overrides доступно всем с test_plan:read
на namespace.

Дальше: страница Run View объясняет,
как live-страница рендерит эти overrides. Страница
Отчёт о прогоне плана — как они
проявляются в экспортах (с redaction).