-[feedback_upgrade_sisyphus.md](feedback_upgrade_sisyphus.md) — обновление LXC ALT p11 → Sisyphus
-[feedback_skill_confirmation_direct.md](feedback_skill_confirmation_direct.md) — подтверждения от skill'ов спрашивать напрямую, не через lavtomate
-[feedback_no_routes_on_remote_nat_peers.md](feedback_no_routes_on_remote_nat_peers.md) — НЕ добавлять маршруты на удалённой машине за NAT при настройке туннелей; MASQUERADE на нашей стороне достаточно
-[feedback_reverse_zone_ip_allocation.md](feedback_reverse_zone_ip_allocation.md) — При выделении IP всегда проверять файл обратной зоны и сразу записывать туда взятый IP
-[feedback_no_bbr.md](feedback_no_bbr.md) — НЕ включать TCP BBR; оставлять cubic. Не трогать tcp_reordering
-[feedback_lxc_via_ssh_not_pct.md](feedback_lxc_via_ssh_not_pct.md) — В LXC ходить через `ssh root@<ct-ip>`, не через `pct exec` с PVE-host
-[feedback_never_bypass_epm_play.md](feedback_never_bypass_epm_play.md) — НИКОГДА не обходить `epm play` ручной загрузкой бинарей — фиксить prerequisites и повторять
-[reference_remote_ssh_access.md](reference_remote_ssh_access.md) — Доступ к удалённым хостам через reverse-SSH на anyssh.ru: parentglobal=:10337/etersoft, rpi=:10338/root и др.
-[lesson_anyssh_ru_in_91232225.md](lesson_anyssh_ru_in_91232225.md) — anyssh.ru = 91.232.225.8, не маршрутизировать всю /24 через туннель
-[lesson_lavtomate_bug_create_confirmation.md](lesson_lavtomate_bug_create_confirmation.md) — bug_create сломан: НЕ ретраить, проверять через confirmation_check
-[lesson_lavtomate_bug_create_confirmation.md](lesson_lavtomate_bug_create_confirmation.md) — bug_create теперь переиспользует approved confirmation_id при field-validation reject; можно ретраить с дополненными полями
-[lesson_dns_free_ip_check_both_zones.md](lesson_dns_free_ip_check_both_zones.md) — поиск свободного IP: проверять ОБЕ зоны (forward+reverse) и ping
- Сброс пароля AD: `логин + uidNumber`
- DC: `ssh -p32 dc.etersoft.ru` (lav, потом sudo), samba-tool через sudo
При выборе свободного IP в наших подсетях (например `91.232.225.0/24`):
1.**Проверять через файл обратной зоны** (`/var/lib/bind/zone/225.232.91.in-addr.arpa` на ns1.etersoft.ru), а не только через `dig -x` и ping.
-`dig` может вернуть пусто для IP, который зарезервирован комментарием в файле (например, диапазоны для devel.etersoft.ru, контейнерных пулов и т.п.)
-`ping` ничего не скажет про офлайн-резервы
- Файл — единственный source-of-truth для нашего policy IP-выделения
2.**Сразу записывать взятый IP** в reverse zone (PTR-запись + при необходимости комментарий о владельце/назначении), даже если хост не сразу поднят. Иначе тот же IP кто-то возьмёт повторно.
**Why:** Пользователь явно сказал «проверяй через файл обратной зоны. и всегда туда записывай взятые» (2026-05-28). До этого я взял `91.232.225.150`, опираясь на пустой `dig -x` и ping — а в файле там был комментарий «150-169 — адреса для контейнеров на devel.etersoft.ru», т.е. зарезервированный пул.
**How to apply:**
- В dns skill при запросе «find free IP / verify free IP» всегда читать reverse zone file целиком (через ssh ns1 sudo cat), искать как PTR-записи так и комментарии-резервы.
- При регистрации нового IP — обязательно PTR в reverse zone + комментарий, если есть особое назначение.
- См. также: [[lesson-dns-free-ip-check-both-zones]]
name:lavtomate bug_create — НЕ ретраить при approved
description:bug_create в lavtomate сейчас ломает confirmation flow — каждый ретрай создаёт новый pending confirmation, и пользователь получает кучу одобрений в web UI без эффекта
name:lavtomate bug_create — confirmation переиспользуется при field-validation reject
description:На 2026-05-31 bug_create корректно переиспользует approved confirmation_id при повторном вызове с дополненными полями (op_sys/rep_platform). Старая проблема с лавиной pending одобрений починена.
В lavtomate `mcp__lavtomate__bug_create` — сломанный confirmation flow (на 2026-04-28). Каждый вызов создаёт НОВЫЙ `confirmation_id`. После approve в web UI `confirmation_check` возвращает `status: approved, success: true` — но бага НЕ создаётся (нет `bug_id` в result). Повторный вызов bug_create не использует уже approved confirmation, а создаёт ещё один pending.
**Why:** Пользователь жаловался — "почему я три раза подтверждал?" Я делал ретраи bug_create с разными product/component, не понимая что Product not found приходила ПОСЛЕ approve каждой попытки. Получилось 3+ pending одобрений в web UI без результата.
## Текущее поведение (2026-05-31, подтверждено на Etersoft#19124)
**How to apply:**
1.Не ретраить `bug_create` после ошибки — сначала проверять через `confirmation_check`.
2.Если `confirmation_check` возвращает approved но bug_id отсутствует — это баг lavtomate, остановиться и сообщить пользователю.
3.Перед bug_create обязательно найти точное имя product/component через `bug_search_products` И сверить совпадение в выдаче существующих баг (`bug_search` по этому product) — `bug_create` хуже матчит русские названия чем `bug_search_products`.
3.`confirmation_check` возвращает `status: approved` + либо `result.bug_id` (успех), либо `result.ok: false` + `valid_*` списки (например `valid_op_sys`, `valid_rep_platform`) — field-validation reject
4.Повторный вызов `bug_create` с **тем же текстом + дополненными полями** → возвращает **тот же `confirmation_id`** и сразу `success: true` + `bug_id`. **Без второго подтверждения.**
См. также: `feedback_skill_confirmation_direct.md`.
**Why:** Раньше (на 2026-04-28) каждый ретрай создавал НОВЫЙ pending confirmation, что бесило. К 2026-05-31 lavtomate починен — confirmation теперь идёт по тексту, а не по полям. Подтверждено в Etersoft#19124: один approve, два вызова, единый ID.
## How to apply
1. Если `confirmation_check` вернул `status: approved` + `result.ok: false` + `valid_*` списки — это field-validation reject, **можно сразу ретраить bug_create с дополненными полями**. Второго одобрения пользователь НЕ получит.
2. Если `confirmation_check` вернул approved + result без `bug_id` и без `valid_*` — вот это уже подозрительно, остановиться и сообщить.
3. Перед первым вызовом всё равно сверить product/component через `bug_search_products` и существующие баги — `bug_create` хуже матчит русские названия.
4. Etersoft требует поля: `op_sys`, `rep_platform`, `priority` (валидные значения см. в `valid_*` из reject-ответа; rep_platform на Etersoft: `PC`, `aarch64`, `Эльбрус`, `Macintosh`, `All`, `Other` — НЕ `x86_64`).
См. также: `feedback_skill_confirmation_direct.md`, `feedback_alt_bugzilla_defaults.md`.
