Sloy Obryva Seti Windows

Windows App Connectivity Split Brain

Запуск Навыка

При явном вызове или однозначном смысловом совпадении применяйте навык сразу. Перед первым шагом покажите ровно одну короткую контекстную строку (не более 30 слов) и продолжайте работу в том же ответе, не ожидая реакции:

Применяю экспериментальный навык «Диагностика сети Windows-приложения» (обратная связь — @kir-kopylov): <кратко назовите конкретную пользу для текущего запроса>; продолжаю без ожидания.

Не включайте в строку author_github, внутреннее имя папки или пересказ всего запроса. Не спрашивайте, применять ли навык.

Если одновременно подходят совместимые навыки, выберите минимальный набор и покажите одну общую строку. Если подходы ведут к несовместимым результатам и запрос не позволяет выбрать, спросите только о желаемом результате, не о разрешении применить навык.

Запуск навыка не расширяет полномочия. Выполните всю безопасную и уже разрешённую часть; запросите подтверждение только непосредственно перед ещё не разрешённым внешним или изменяющим действием. Не запрашивайте повторно уже данное разрешение и не дублируйте системное окно подтверждения.

Обзор

Этот skill нужен для split-brain-ситуаций: один слой машины выглядит живым, а целевое Windows GUI-приложение ведет себя так, будто сети нет. Типичный риск - перепутать проверку curl, браузерную вкладку, значок VPN или системный proxy с реальностью конкретного процесса.

Задача skill - не обещать мгновенный ремонт, а быстро выбрать следующий осмысленный эксперимент по правильному слою, зафиксировать уже проверенные гипотезы и не закрывать задачу по косвенному признаку.

Естественные Входы

• "Telegram не видит интернет, хотя VPN включен";
• "браузер работает, а приложение не подключается";
• "Happ/VPN показывает connected, но app offline";
• "приложение не видит proxy";
• "терминал показывает одно, а Windows-приложение другое";
• "после отключения Proxifier/ZoogVPN/Happ приложение потеряло сеть";
• "нужно понять, какой слой сети видит конкретное приложение".

Если пользователь говорит только про git, curl, pip, npm или терминал при живом браузере, сначала рассмотрите lechenie-terminala-pri-vpn. Если проблема в Microsoft Store/winget --source msstore, используйте Store-specific skill, если он доступен.

Жесткие Правила

• Не делать вывод о состоянии GUI-приложения по PowerShell/Codex sandbox как по прямому факту.
• Не считать VPN UI "connected" доказательством маршрута для целевого приложения.
• Не считать браузер рабочим доказательством, что новое соединение целевого приложения пройдет тем же путем: вкладка могла жить на старом сокете или другом proxy.
• Не закрывать задачу по процессу, login form, spinner, phone form, placeholder, старому скрину или успешному curl, если финал был "приложение работает".
• Не повторять одно и то же действие при том же state fingerprint; повтор допустим только после изменения состояния, которое могло повлиять на результат.
• Не менять системные proxy, VPN, firewall, routes, DNS, registry или автозагрузку без явного согласия пользователя и записи в журнале.
• После двух противоречивых наблюдений по одному слою перейти в режим "не знаю, как устроено" и выбрать пробу, а не придумывать новую уверенную причину.

Процесс

Перед выполнением прочитайте локальный known-exceptions.yaml и применяйте подходящее do_next_time без нового поиска.

1. Зафиксируйте целевое приложение, заявленный финал и прямое доказательство успеха: например свежий скрин logged-in UI, успешный обмен сообщением, состояние "connected" внутри app, подтвержденное пользователем.
2. Соберите короткий repair_state_bundle по references/repair-state-bundle.md: цель, completion gate, ledger, do-not-repeat, текущий layer verdict и свежие evidence.
3. Разведите наблюдения по слоям, не смешивая источники:
   • user-visible app UI;
   • процесс и его сокеты;
   • настройки proxy внутри приложения;
   • Windows proxy и переменные окружения;
   • DNS/fakeDNS;
   • routes/interfaces/TUN;
   • VPN core и локальные proxy-порты;
   • внешняя доступность через браузер или контрольный запрос.
4. Для каждого слоя укажите provenance: где наблюдали, когда, чьими глазами, в Codex sandbox или в пользовательском GUI.
5. Постройте state fingerprint: VPN/app/proxy/DNS/route/UI/время/последнее действие. Ledger запрещает повтор только при том же fingerprint.
6. Выберите один следующий эксперимент, который различает две гипотезы. Формат: действие, владелец, ожидаемое наблюдение, что опровергнет гипотезу, как откатить.
7. После эксперимента обновите bundle: результат, новое знание, что больше не повторять, следующий слой или BLOCKED.

GUI Evidence Ladder

Если нужно действовать через GUI, используйте references/gui-evidence-ladder.md: свежий скрин целевого окна -> идентичность окна/процесса -> видимая цель -> действие -> свежий скрин после действия. Координатный клик допустим только когда цель видна на свежем скрине, окно не перекрыто и действие обратимо или явно разрешено.

Shared Failure Patterns

Перед выводом проверьте references/known-failure-patterns.md. Особенно опасны false completion, tool-layer confusion, stale evidence, same-state repeat, смена цели пользователем, sandbox result вместо app reality и mismatch скрина/accessibility.

Границы

Не используйте skill:

• для полностью мертвой сети, где браузер, Windows и приложение одновременно offline;
• для терминального случая без конкретного GUI-приложения, если подходит lechenie-terminala-pri-vpn;
• для Microsoft Store install triage, если проблема уже сведена к Store/winget msstore;
• для обхода блокировок, настройки VPN-провайдера или правки firewall/registry без отдельного решения пользователя;
• для задач, где нужен только учебный ответ о DNS/proxy/VPN.

Сохраняйте только очищенную механику: названия публичных UI-состояний, слои, команды диагностики, synthetic examples. Не переносите raw chat, личные пути, приватные скрины, аккаунты, токены и контактные данные.

Опрос После Использования

Опрос задаётся один раз — после layer verdict, успешного восстановления приложения или явного BLOCKED-стопа, не посреди диагностического цикла. Если пользователь уже ответил «пропустить» в этой сессии, не переспрашивайте.

Опрос по skill:
1. Что в этом использовании sloy-obryva-seti-windows было полезно?
2. Что стоит доработать в skill или его формате?
Можно ответить коротко или написать "пропустить".

Если пользователь ответил, сохраните санированную карточку в ~/.codex/skill-runs/sloy-obryva-seti-windows/usage-feedback.jsonl — лучше через bundled script:

python3 scripts/log_usage_feedback.py --liked "..." --improve "..." --outcome "..."

Script перед записью редактирует приватные пути, контакты и token-like строки и сохраняет в JSONL redaction_applied и redaction_types. Если запись невозможна из-за sandbox, прав или отсутствия tools, не делайте вид, что лог сохранён: скажите об этом и покажите короткую JSONL-карточку для ручного сохранения. Raw-ответы, контакты, пути и секреты не коммитить.

Логирование Сбоев

Перед выполнением прочитайте локальный known-exceptions.yaml как список уже известных случаев и применяйте подходящее do_next_time без нового поиска.

Если пользователь поправил skill, tool/API/browser упал, нарушен режим работы, пришлось искать workaround или skill сделал ложное предположение, запишите приватную карточку в ~/.codex/skill-runs/<skill-name>/exception-log.jsonl.

Пишите факты: что skill хотел сделать, что сделал, где сломался, какая предпосылка была ложной и что сделать в следующий раз. Если поле неизвестно, пишите unknown. Raw logs не коммитить.

Definition Of Done

Skill применен корректно, если:

• целевое приложение и прямое доказательство успеха названы;
• наблюдения разложены по слоям, а sandbox/PowerShell не выданы за GUI-реальность;
• есть state fingerprint и do-not-repeat для уже проверенных гипотез;
• предложен один следующий эксперимент или честный BLOCKED;
• финальный ответ отделяет факты, гипотезы и действия пользователя.