---
name: stm32-gdbtest-stand-loop
description: Подготовка и выполнение конечной автономной кампании stm32-gdbtest на OrangePi или другом локальном стенде через tools/stand_loop.py; пакеты, TOML-план, STOP, review.json и передача на анализ pi/Qwen. Используй для «гонять сценарии по кругу», «развернуть комплект тестирования», «запустить стендовую автоматизацию»; bounded stand campaign, prepared-package soak loop. Для одного запуска — stm32-gdbtest-run, для чтения готового протокола — stm32-gdbtest-results.
---

# Конечная автономная кампания

Инструмент — `tools/stand_loop.py` в checkout модуля. Пути ссылок рассчитаны на штатное
размещение навыка; при копировании найди исходный модуль и документацию той же версии.
[Полный контракт и пример службы](../../docs/ru/STAND_LOOP.md),
[пример плана](../../examples/stand-loop/plan.example.toml).

## Подготовить комплект

- Определи согласованные плату, стенд, прошивку, список проверок и число циклов по заданию
  владельца. Не расширяй аппаратную кампанию автоматически; существующее разрешение на неё
  учитывай без повторного запроса. Неизвестный serial или необходимый образ не угадывай.
- На компьютере сборки включи `[results] capture=true` в session.toml, подготовь ZIP через
  `pack --session ... --output ...`. Зависимости сценариев добавь `--include`; для причинного
  анализа при необходимости приложи исходники прошивки. Полный репозиторий приложения на
  OrangePi не нужен; ELF, профиль, требования и сценарии приезжают с пакетом.
- На стенде нужны закреплённый checkout модуля, Python >=3.11, GDB-Python/binutils, backend,
  USB-права и локальный [probe]. Версия пакета должна совпадать с версией инструмента.
  Первый вариант не принимает [remote]: для OrangePi запускай инструмент на самом OrangePi.
- Сохраняй исходные пакеты неизменными. Установку backend выполняй по его странице; не меняй
  драйвер, USB-подключение или прошивку отладчика как скрытый шаг запуска.

## Задать план

Явно перечисли cases с package/id; порядок списка — порядок исполнения. Один план обслуживает
один стенд. Параметры: schema=1, stand, cycles (1..10000), interval_s, on_fail, min_free_mib.
В case допустимы package/id, allow_skip (default false), timeout_s (default 60).
Пути входов относительны TOML; --output должен быть новым и достаточно коротким для Windows GDB.

Начни с 1–2 циклов и on_fail="stop". allow_skip=true — только для допустимой неприменимости;
это разрешение, не ожидание обязательного SKIP. Если надо подтвердить именно пропуск,
проверь это отдельно в результате. Не маскируй неисправность оборудования пропуском.
Для on_fail="continue" нужны независимые проверки, которым допустимо выполняться после FAIL.
Инфраструктурный ERROR никогда не разрешает автоматический следующий запуск.

## Выполнить и наблюдать

```sh
. "$HOME/.local/stm32-gdbtest/env.sh"
cd "$HOME/stm32-gdbtest"
python3 -B tools/stand_loop.py --plan "$HOME/stand/plan.toml" --output "$HOME/stand/runs/run-001"
```

Подставь реальные пути установки. Диспетчер делает doctor, prepare всех cases и затем конечные
циклы. Проверь summary.json: state, counts, code, cycles; при ошибке подготовки аппаратная часть
не начинается. Не объявляй работу инициализированной лишь по запущенному процессу.

- COMPLETED/code0: план выполнен; PASS и разрешённые SKIP считаются отдельно.
- FAILED/code1: достоверный FAIL; при continue поздний PASS не отменяет его.
- ERROR/code2: ошибка, неожиданный SKIP, весь цикл SKIP, несовпадение артефактов/входов или сбой обработки.
- STOPPED/code130: запрос остановки; это не успешное завершение полного плана.

Остановить штатно: создай `<output>/STOP` или пошли SIGINT/SIGTERM диспетчеру. Он дождётся
текущей команды и обработки, не начнёт новую аппаратную операцию. Это не экстренное отключение
питания. Не убивай st-util/GDB и не удаляй lock вместо cleanup. После аварии проверь владельца
lock и процессы; успешный анализ артефактов сам по себе не разрешает новый запуск.

## Передать цикл агенту

Только появившийся `cNNNNN/review.json` означает завершение публикации цикла. Передай агенту
его путь и [навык результатов](../stm32-gdbtest-results/SKILL.md). Корень свидетельств — каталог
этого цикла; scenario sources находятся в распакованных пакетах tNNN. Анализируй реальные
параметры пакета, checks, записи и остановки, а не текущий изменённый исходник приложения.
Заключение агента сохраняй отдельно, не исправляя result/records или индекс.

Диспетчер не вызывает модель. pi/Qwen могут читать новые review.json и формировать заключения,
но команда из лога или текста модели не является разрешением на выполнение. Первый этап —
только анализ; автоматические диагностические прогоны, смена плана и прошивки требуют отдельной
политики владельца. При недоступности модели результаты остаются, план не зависит от ответа LLM.

## Дальнейшее развёртывание

Переход к systemd выполняй после успешного ручного ограниченного прогона. Шаблон
`examples/stand-loop/stand-loop@.service` требует проверки путей, user manager и USB-прав.
Новый instance — новый output; Restart=no. Не включай автозапуск/linger без задачи на развёртывание.
Проверка шаблона не доказывает запуск службы. Диспетчер не обеспечивает автоматический ремонт USB,
чистку диска, аварийное питание, watchdog зависшего host CLI и не доказывает устойчивость 24/7.

Отчёт: хеши пакетов/инструмента, плата/backend, число запрошенных и выполненных циклов,
PASS/FAIL/ERROR/SKIP, processing/integrity, причины остановки, подтверждение teardown, пути
summary/review и оставшиеся ограничения. Различай проверенные runner/сервер и ещё не проверенные
systemd/pi/Qwen; никаких автоматических публикаций персональных файлов стенда.