---

Ты — Codex на моём выделенном Windows-компьютере. У тебя нет истории моего чата на Mac, поэтому ниже полный контекст и поручение.

Твоя задача — непосредственно настроить этот Windows-ПК как удалённый тестовый стенд для игры УРМАН. Не ограничивайся рекомендациями или планом: установи необходимые инструменты, получи репозиторий, подготовь и запусти минимальный исполнитель тестовых заданий, подготовь клиент для Mac/Linux/Codex Cloud, инструкции подключения и правила проекта.

Действуй автономно в пределах этого поручения. Когда нужен мой вход в аккаунт, подтверждение UAC или настройка, недоступная тебе технически, попроси только это конкретное действие и продолжай независимую работу.

Не предполагается, что разработку нужно целиком перенести на Windows. Именно это было неверным направлением предыдущего варианта настройки.

================================================================
1. ЧТО Я ХОЧУ ПОЛУЧИТЬ
================================================================

Игра: УРМАН.
Репозиторий:
https://github.com/rustemd02/URMAN.git

Возможные места разработки:
- мой MacBook;
- MacBook другого авторизованного разработчика;
- Codex Cloud;
- при необходимости сам Windows-ПК.

Место автоматических игровых проверок:
- этот выделенный Windows-ПК.

Место обычного запуска поиграть:
- компьютер, на котором пользователь явно попросил запустить игру.

Примеры:

«Исправь управление и проверь»
→ код правится в текущем рабочем checkout;
→ точное проверяемое состояние передаётся на Windows;
→ игра/нужная тестовая сцена запускается на Windows;
→ агент получает логи, результат и необходимые кадры;
→ окно игры на MacBook не открывается.

«Сделай скриншоты деревни для проверки»
→ захват выполняется на Windows.

«Прогони игровой benchmark»
→ выполняется на Windows.

«Я хочу поиграть, запусти игру»
→ игра запускается локально на компьютере пользователя;
→ запрос не отправляется на тестовую Windows-станцию.

«Продолжай разработку»
→ само по себе не означает запускать игру после каждой правки;
→ сначала достаточная статическая проверка/узкая компиляция;
→ игровой запуск только когда он действительно нужен для задачи.

Если Windows-станция недоступна:
- не запускать игру на Mac автоматически;
- сообщить конкретную причину;
- продолжить независимую работу;
- игровую проверку оставить not-run;
- локальная автоматическая проверка допустима только после явного разрешения пользователя на этот конкретный запуск.

Наличие доступа не означает, что надо постоянно тестировать игру.

================================================================
2. КОНТЕКСТ РЕПОЗИТОРИЯ
================================================================

УРМАН — Godot .NET/C# проект.

На момент подготовки этого поручения закреплены:
- Godot 4.7.1 .NET;
- .NET SDK 10.0.302.

Но источники истины — файлы актуального репозитория:
- global.json;
- eng/toolchain.json;
- game/Urman.Game.csproj.

Не устанавливай случайный latest вместо закреплённых версий.

В репозитории уже подготовлены:
- eng/setup-windows-station.ps1;
- eng/run-windows-check.ps1;
- eng/protected_run.py;
- docs/production/WINDOWS_TEST_STATION_RU.md.

Также существуют локальные Mac-launcher'ы:
- eng/run-act1-demo.sh;
- eng/run-act1-demo-safe.sh;
- eng/run-smoke-guarded.sh;
- eng/dotnet-env.sh.

Проверь их наличие и актуальное содержимое после получения репозитория.

Старый WINDOWS_TEST_STATION_RU.md описывает преимущественно перенос всего рабочего чата на Windows через Remote. Для текущего поручения этого недостаточно. Исправь документ под схему «разработка где удобно → тестирование на Windows».

Не создавай вторую библиотеку запуска Godot, второй механизм защиты сохранений или отдельный источник версий инструментов. Переиспользуй существующее.

Сначала прочитай:
- AGENTS.md;
- docs/urman_knowledge_base/README.md;
- релевантные технические документы;
- актуальные записи decision_log.md.

Не восстанавливай исторические запреты владения файлами дорожек: они отменены поручением автора 03.10.2026. При этом сохраняй полезные чужие изменения.

В AGENTS.md также есть запрет игровых запусков для текущего статического аудита. Это поручение — отдельная настройка стенда: для её приёмки разрешён один необходимый ограниченный запуск на Windows и один необходимый захват кадра. Это не разрешение возобновлять игровые запуски остальных аудитов и не разрешение запускать проверки на Mac.

================================================================
3. ГРАНИЦЫ ПОРУЧЕНИЯ
================================================================

Разрешено:
- устанавливать недостающие инструменты для стенда;
- клонировать этот репозиторий на Windows;
- обновлять существующий чистый Windows-checkout безопасным способом;
- создавать инфраструктуру приёма тестовых заданий;
- менять необходимые инфраструктурные файлы проекта;
- добавить согласованные ниже правила в AGENTS.md;
- подготовить клиентские команды для Mac и Cloud;
- зарегистрировать автозапуск исполнителя в пользовательской Windows-сессии;
- выполнить необходимые проверки настройки на Windows.

Не разрешено автоматически:
- покупать услуги;
- менять настройки роутера;
- публиковать рабочий стол или исполнитель в открытый интернет;
- отключать Defender, Firewall или общие средства защиты;
- включать автоматический вход в Windows с сохранённым паролем;
- создавать Git worktree или дополнительные Git-клоны ради каждого теста;
- сбрасывать/стирать чужой diff;
- делать git reset --hard, git clean -fdx или stash чужой работы;
- коммитить, пушить, сливать или публиковать изменения без отдельного поручения;
- изменять игровой сюжет или механику ради настройки стенда.

Если опубликование инфраструктурных файлов понадобится для других checkout, сначала подготовь конкретный проверенный diff. Затем объясни, какие файлы требуется передать или опубликовать. Не утверждай, что изменение только Windows-копии AGENTS.md уже действует на Mac и в Cloud.

================================================================
4. ПЕРВЫЙ ЭТАП: ПОДГОТОВИТЬ WINDOWS
================================================================

Проверь:
- версию Windows;
- архитектуру CPU;
- текущего пользователя;
- доступную память и диск;
- видеокарту и драйвер;
- доступность вошедшей пользовательской desktop-сессии.

Не выдавай сведения о модели GPU за доказательство успешного GPU-запуска.

Предпочтительный каталог проекта:
C:\URMAN

Если проекта ещё нет:
1. Проверь Git.
2. Если Git отсутствует, установи официальный Git for Windows.
3. Обнови PATH текущего процесса либо используй обнаруженный полный путь.
4. Выполни git clone нужного репозитория в C:\URMAN.
5. Если нужен вход в GitHub, проведи обычную авторизацию. Не проси пароль/токен текстом в чате.

Если проект уже есть:
- проверь origin, ветку, HEAD и dirty-state;
- не клонируй поверх;
- при чистом checkout можно получить обновления и выполнить допустимое fast-forward обновление;
- при грязном checkout сохрани его состояние и не затирай его ради настройки;
- не переключай чужую работу на другую ветку.

Проверь Python. Для существующих скриптов нужен рабочий Python 3.12+.
Если он отсутствует, установи подходящую стабильную версию официальным способом.

Используй существующий setup-windows-station.ps1 для установки закреплённых .NET/Godot, если он подходит.

Если в нём есть реальные ошибки Windows-исполнения — исправь минимально.

На Windows должны работать:
- C#-компиляция;
- импорт необходимых готовых ресурсов;
- native Godot с настоящим GPU;
- существующая защита userdata.

В проекте может лежать авторский .blend рядом с готовым .glb. Учитывай уже предусмотренный локальный override Blender-import. Не устанавливай огромный набор редакторов лишь для запуска готовых GLB, если он не нужен.

Сначала настрой только зависимости выполнения игры. Blender и инструменты авторинга добавляй лишь при доказанной необходимости.

================================================================
5. ВЫБРАННАЯ МИНИМАЛЬНАЯ АРХИТЕКТУРА
================================================================

Основной вариант:

Mac разработчика / Codex Cloud
          |
          | HTTPS по приватному Tailscale
          v
Windows: небольшой исполнитель заданий
          |
          v
существующий Windows runner → Godot → logs/receipt/frames

Нужен один общий канал для Mac и Cloud, чтобы не поддерживать два независимых протокола тестирования.

Используй:
- Tailscale для частного подключения;
- Tailscale Serve для частного HTTPS-доступа;
- небольшой локальный исполнитель;
- один переносимый клиент на Python для Mac/Linux/Cloud.

Не добавляй Docker, Kubernetes, базу данных, брокер сообщений, веб-панель, Agents API, отдельную платную облачную инфраструктуру или свой аналог Codex.

Предпочтительно стандартная библиотека Python. Если небольшой уже установленный компонент решает задачу проще и надёжнее — используй его.

Это исполнитель игровых проверок, а не новый агент разработки и не произвольный публичный shell.

Проверь актуальные официальные инструкции Tailscale/Codex Cloud перед настройкой. Не копируй устаревшие команды из памяти.

================================================================
6. СЕТЬ И АВТОРИЗАЦИЯ
================================================================

Установи Tailscale на Windows, если он отсутствует.

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

Исполнитель должен слушать loopback, например:
127.0.0.1:8765

Частный HTTPS-доступ организуй через Tailscale Serve.
Не используй Tailscale Funnel и не делай сервис публичным.

Настрой доступ для:
- моего Mac;
- компьютера второго разработчика;
- VPN-идентичности нужного Cloud environment.

Не выдавай второму разработчику весь мой аккаунт или общий личный пароль.

Дополнительно защити операции исполнителя токеном.
Секреты:
- генерировать криптографически стойко;
- хранить вне Git;
- не печатать в логах и итоговом ответе;
- не записывать в AGENTS.md;
- не включать в архивы исходников и результатов.

Разрешённые сетевые назначения и клиентские параметры без секретов можно хранить в конфигурации проекта.

Не меняй глобальные permissions Codex на unrestricted лишь ради одного HTTPS-адреса. Подготовь минимальное разрешение нужного назначения там, где оно требуется.

Если настройка tailnet, HTTPS или доступа аккаунта требует действий владельца, укажи конкретную кнопку/поле и значение без секрета. Не останавливай подготовку файлов и независимую настройку.

================================================================
7. WINDOWS-ИСПОЛНИТЕЛЬ
================================================================

Он должен поддерживать необходимый минимум:
- состояние/готовность стенда;
- приём снимка исходников;
- запуск одной игровой проверки;
- запуск одного захвата;
- получение состояния задания;
- получение logs, receipt и кадров.

Используй существующий run-windows-check.ps1 как основу запуска.
Не обходи protected_run.py.

Важно: текущий runner предполагает наличие .git и .tools внутри checkout. Снимок исходников будет другим каталогом. Минимально адаптируй runner:
- принимать явный каталог исходников;
- использовать закреплённые инструменты станции;
- принимать проверенный manifest происхождения снимка;
- не требовать выдуманного Git-коммита для незакоммиченного снимка.

Не создавай фиктивный .git ради receipt.

Параметры задания должны быть структурированными:
- идентификатор снимка;
- режим;
- существующая тестовая сцена или сцена демо;
- timeout;
- headless/native;
- параметры существующего захвата.

Не принимай произвольную строку shell-команды от сети.
Не подставляй пользовательский ввод в PowerShell/Bash через конкатенацию.
Пути сцен, режимы и допустимые параметры проверяй.

Код снимка выполняется только от доверенных авторизованных разработчиков. Не подключай исполнение посторонних PR/fork к этому компьютеру.

Одновременно разрешён один игровой запуск.
Сборка, импорт и запуск сериализуются.

Если станция занята:
- вернуть понятный статус и идентификатор выполняющегося задания;
- клиент может ограниченно ждать;
- не запускать второй Godot;
- повторный запрос с тем же идентификатором не должен дублировать запуск.

Не строить сложный менеджер очередей. Одного исполнителя с простым состоянием на диске достаточно.

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

При перезапуске исполнителя незавершённое задание нельзя объявлять PASS.

================================================================
8. КАК ДОЛЖНО ПОЯВЛЯТЬСЯ ОКНО НА WINDOWS
================================================================

Godot запускается в вошедшей пользовательской Windows desktop-сессии.

Недостаточно просто иметь Windows-процесс:
- headless не доказывает графику;
- служба в Session 0 не заменяет рабочий стол;
- подключение через SSH само по себе не доказывает нужную GUI-сессию.

Исполнитель запускай под обычным пользователем стенда.

Для автозапуска используй Windows Task Scheduler с интерактивным входом пользователя — запуск после logon, в его desktop-сессии.

Не устанавливай GUI-исполнитель как системную службу под SYSTEM.

Не включай автологин и не сохраняй пароль Windows ради автоматизации.
После перезагрузки пользователь может один раз войти в Windows.

Готовность стенда должна отражать:
- запущен ли исполнитель;
- доступны ли инструменты;
- есть ли нужная пользовательская сессия;
- есть ли незавершённое восстановление userdata;
- занят ли стенд.

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

Для кадров сначала используй встроенный игровой захват, а не снимок всего рабочего стола с личными окнами.

================================================================
9. ПЕРЕДАЧА ТОЧНОГО КОДА
================================================================

Это обязательная часть. Одного git pull недостаточно.

Если агент на Mac изменил C# или .glb, но ещё не сделал commit:
- Windows должен получить именно эти изменения;
- нельзя проверить старый main и выдать результат за проверку нового diff;
- тестирование не должно требовать push после каждой правки.

Клиент должен собирать снимок необходимых исходников и runtime-ассетов из текущего рабочего дерева.

Снимок должен включать:
- текущие изменённые tracked-файлы;
- новые нужные исходники и ассеты;
- отсутствие удалённых файлов;
- необходимые проекты, content, конфигурации и скрипты.

Не включать:
- .git;
- локальную .tools;
- game/.godot;
- bin/obj;
- caches;
- прежние screenshots/receipts;
- node_modules;
- секреты, .env и файлы ключей;
- ненужный graphify-out.

Проверить реальные зависимости проекта, а не выбирать случайные пять файлов.

У снимка должен быть manifest:
- repository identity;
- базовый Git commit, если он есть;
- сведения о dirty-state;
- список файлов;
- SHA256 файлов;
- идентификатор снимка.

Если рабочие файлы менялись прямо во время упаковки, обнаружить это и не выдавать несогласованный архив за точный снимок.

Windows распаковывает снимок в отдельный каталог данных конкретного запуска, например:
C:\URMAN-STATION\runs\<job-id>\source

Это не дополнительный Git-клон и не worktree. В рамках этого поручения такие временные каталоги переданных исходников разрешены.

Основной Windows-checkout не затирать снимками с Mac.

Перед распаковкой:
- проверить пути;
- запретить выход из каталога;
- запретить небезопасные ссылки;
- учесть Windows reserved names и коллизии регистра;
- ограничить размер загрузки и распакованного содержимого;
- проверить manifest и хеши.

Лимиты должны соответствовать реальному размеру проекта, а не условным 10 МБ.

После сборки записать идентичность полученного снимка и hash игровой DLL.

Не внедрять сложную дельта-синхронизацию заранее. Сначала корректный снимок. Если передача измеримо слишком тяжёлая, тогда оптимизировать повторную передачу неизменных ассетов.

================================================================
10. СОХРАНЕНИЯ И ЗАВЕРШЕНИЕ ПРОЦЕССОВ
================================================================

Автоматические проверки всегда защищают пользовательские saves/preferences через существующий guard.

Не подменяй этот механизм простым удалением userdata.

Нужно сохранить:
- отдельную чистую тестовую сессию;
- сериализацию;
- восстановление исходных данных;
- marker незавершённого восстановления;
- подтверждение восстановления;
- прекращение игрового процесса до возвращения исходных saves.

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

Если данные не удалось восстановить или процесс не удалось завершить:
- FAIL;
- сохранённые recovery-данные;
- понятные пути и причина;
- запрет следующего запуска до разрешения ситуации.

Не объявлять Windows ACL проверенными, если механизм их отдельно не проверяет.

================================================================
11. ПЕРЕНОСИМЫЙ КЛИЕНТ
================================================================

Подготовь один клиент, который работает:
- на macOS;
- на Linux;
- в Codex Cloud;
- локально на Windows для диагностики.

Предпочтительно Python без новых зависимостей.

Интерфейс должен быть простым, например:

python3 eng/remote-check.py doctor
python3 eng/remote-check.py smoke --scene res://tests/НУЖНАЯ_СЦЕНА.tscn
python3 eng/remote-check.py capture --points "..."
python3 eng/remote-check.py status --job-id ...
python3 eng/remote-check.py fetch --job-id ...

Это примеры интерфейса, не требование создать именно столько файлов/команд. Если проще — сократи.

Клиент:
- читает адрес и авторизацию из конфигурации/окружения;
- проверяет доступность;
- отправляет точный снимок;
- получает идентификатор задания;
- ждёт результат ограниченно;
- скачивает результат в локальный каталог артефактов;
- возвращает ненулевой exit при провале;
- не запускает локальный Godot при сетевой ошибке.

Он должен поддерживать стандартный HTTPS-proxy окружения Cloud. Не отключай проверку сертификатов и не добавляй --noproxy как универсальное «исправление».

В локально скачанных результатах должны быть:
- receipt;
- stdout/stderr;
- engine errors;
- screenshots при соответствующем запросе.

Агент на Mac/Cloud должен иметь возможность прочитать логи и посмотреть полученный игровой PNG своими доступными инструментами.

Это не требует переносить чат на Windows и не зависит от синхронизации локальных чатов.

================================================================
12. ПОДКЛЮЧЕНИЕ МОЕГО MAC И MAC ДРУГОГО РАЗРАБОТЧИКА
================================================================

Подготовь точную короткую инструкцию для каждого Mac:
- установка/подключение Tailscale, если отсутствует;
- доступ к нужному Windows-узлу;
- получение актуальных инфраструктурных файлов проекта;
- настройка адреса;
- настройка личного секрета вне репозитория;
- проверка doctor;
- отправка одного необходимого задания;
- чтение результатов.

Не предполагается, что ты сейчас физически управляешь обоими Mac.

Если подключиться к ним нельзя, подготовь всё, что можно на Windows, и дай команды для оставшихся действий. Не называй Mac-подключение проверенным до реального запроса с Mac.

У обоих разработчиков одинаковый клиент и правила маршрутизации. Не создавать отдельную реализацию для «компьютера друга».

================================================================
13. CODEX CLOUD
================================================================

Подготовь подключение к той же Windows-станции из актуального Codex Cloud.

Сначала проверь текущие официальные возможности и интерфейс аккаунта:
https://learn.chatgpt.com/docs/environments/cloud-environments

Предпочтительный вариант:
- Cloud environment;
- встроенное подключение Tailscale VPN;
- разрешённый HTTPS-адрес станции;
- авторизация HTTP через настроенный secret;
- тот же Python-клиент и протокол.

Для Tailscale Cloud-идентичности используй документированный способ. Не помещай auth key в Git.

Если доступен Network secret для HTTPS, используй его с точным allowed destination. Не смешивай этот механизм с legacy setup-only secrets.

Если аккаунт использует Legacy Codex Cloud:
- явно установи его ограничения сети и секретов;
- не обещай доступ в agent phase через секрет, который существует только во время setup;
- не обходи это сохранением секретов в репозиторий.

Если нужного VPN/сетевого механизма в аккаунте нет:
- точно назови отсутствующую возможность;
- заверши Windows и Mac-часть;
- подготовь конкретный альтернативный путь, прежде чем предлагать его;
- Cloud оставь not-configured до фактической проверки;
- не публикуй стенд наружу автоматически ради обхода ограничения.

Доступ Cloud к HTTP-сервису не означает доступ его Computer Use к Windows. Для первого варианта нужны задания, логи и встроенные кадры; не обещай несуществующее управление рабочим столом из Cloud.

В инструкции Cloud укажи:
- что настроить в environment;
- куда внести значения и секреты;
- какой адрес разрешить;
- нужно ли publish/republish;
- как проверить doctor из нового Cloud-задания;
- как отправить снимок с незакоммиченными изменениями.

================================================================
14. ПРАВИЛА ПРОЕКТА В AGENTS.md
================================================================

В рамках именно этого поручения я разрешаю добавить небольшой раздел в AGENTS.md.

Не переписывай файл целиком, не возвращай старые удалённые правила и не добавляй новые запреты на всё подряд.

Смысл нового раздела:

1. Перед игровым запуском определить цель:
   - автоматическая проверка;
   - явный пользовательский запуск поиграть.

2. Автоматические игровые проверки, visual captures и benchmarks направлять на Windows-станцию через штатный клиент проекта.

3. Разработка остаётся в текущем рабочем checkout.

4. При недоступности станции локальный запуск не является автоматическим fallback. Сообщить причину и продолжить независимую работу.

5. Явная просьба пользователя запустить игру для игры/просмотра выполняется локально на его текущем компьютере.

6. Обычные статические проверки и узкая компиляция, не запускающие движок, могут выполняться локально.

7. Не тестировать после каждой правки по привычке. Выбирать минимальную необходимую проверку.

8. Удалённый результат относится только к конкретному снимку/коммиту, идентичность которого подтверждена receipt.

9. Секреты не хранить в инструкциях. AGENTS.md ссылается на клиент и один актуальный документ настройки.

10. Отдельный действующий запрет игровых проверок в конкретной задаче сохраняет силу. Политика маршрутизации не является разрешением запускать движок.

Не делай глобальный запрет Mac-Godot: он сломает требуемое исключение «запусти поиграть».

Не ставь безусловную блокировку в protected_run.py, который отвечает за сохранения. Маршрутизация и guard — разные обязанности.

Если нужен единый launcher с явными режимами test/play — сделай минимально и сохрани существующие рабочие локальные команды.

Если намерение пользователя неоднозначно, не захватывай управление Mac автоматически.

================================================================
15. АКТУАЛЬНОСТЬ ЗАПУСКА НА MAC И WINDOWS
================================================================

Обе платформы должны использовать:
- общий content;
- согласованные закреплённые версии;
- свежую C#-сборку;
- существующие правила защиты данных.

Не копируй Mac-бинарники .tools на Windows и наоборот.

Изучи существующий путь обновления compiled content. Сейчас Mac-launcher перед игрой обновляет campaign packs. Windows-путь не должен незаметно использовать устаревший pack после изменения authoritative content.

Исправляй только доказанные различия, мешающие этой настройке.

Не строй большую систему cross-platform bootstrap заново.

На Windows ты можешь проверить Windows-путь.
Mac-путь без Mac-проверки отмечай inspected/not-run. Не выдавай статическое чтение shell-script за выполненный Mac-запуск.

Обычный запуск поиграть не должен внезапно менять прежний контракт сохранений только из-за новой маршрутизации.

================================================================
16. РЕЗУЛЬТАТЫ ЗАДАНИЙ
================================================================

Receipt должен позволять ответить:
- какая станция выполнила задание;
- какой снимок она получила;
- какой базовый commit у снимка;
- что было изменено;
- какие версии Godot/.NET использованы;
- какая DLL была запущена;
- какая сцена и режим;
- был ли запуск native или headless;
- сколько длился;
- какой exit code;
- какие ошибки;
- подтвердил ли guard восстановление;
- где кадры.

PASS нельзя выдавать:
- по одному доступному health endpoint;
- по запуску старого main вместо нового снимка;
- по headless вместо проверки GPU;
- по exit 0 при фактических ошибках harness;
- по наличию картинки без завершения проверки.

Технический прогон не является художественной приёмкой, человеческим плейтестом или доказательством длительности/интереса игры.

================================================================
17. ПРОВЕРКА НАСТРОЙКИ
================================================================

Проведи минимально достаточную приёмку, без полного игрового набора:

A. Исполнитель запускается в правильной Windows-сессии.
B. Без корректной авторизации задание не принимается.
C. Принят точный снимок и подтверждены хеши.
D. Выполнена одна существующая короткая native-проверка на Windows.
E. Получен один необходимый игровой PNG.
F. Получены receipt и логи.
G. Подтверждено восстановление userdata.
H. Повтор/конкурентный запрос не породил второй игровой запуск.

Не создавай новые игровые тестовые suites, fixtures или mocks ради этого поручения. Используй существующие сцены и самые узкие проверки инфраструктуры.

Предпочтительно отправить native-проверку через тот же HTTP-клиент, а не запускать runner вручную и отдельно заявлять, что удалённый путь работает.

Реальные проверки с Mac и Cloud выполняй только при их фактической доступности.

Если сейчас доступен лишь Windows-клиент:
- это подтверждает worker/client protocol;
- это ещё не подтверждает связь Mac→Windows и Cloud→Windows;
- напиши об этом точно.

================================================================
18. ЧТО ПОДГОТОВИТЬ В КОНЦЕ
================================================================

Мне нужны:

1. Настроенный и работающий Windows-исполнитель.
2. Минимальные инфраструктурные файлы в репозитории.
3. Один переносимый клиент.
4. Обновлённый гайд, соответствующий нынешней схеме.
5. Небольшой раздел AGENTS.md с исключением для локальной игры.
6. Короткая инструкция подключения моего Mac.
7. Та же инструкция для второго разработчика.
8. Инструкция подключения Cloud.
9. Результаты выполненных проверок.
10. Команда остановки исполнителя и отключения его автозапуска.

Не выдавай десятки дублирующих документов. Обнови существующий гайд и добавь только действительно необходимые файлы.

Для передачи инфраструктурного diff другим компьютерам, если commit/push ещё не разрешён, подготовь конкретный patch/комплект с инструкцией безопасного применения. Не включай чужие изменения.

В итоговом ответе укажи отдельно:
- WINDOWS_WORKER: ready / blocked;
- MAC_CONNECTION: verified / not-run;
- SECOND_MAC_CONNECTION: verified / not-run;
- CLOUD_CONNECTION: verified / not-configured / not-run;
- SOURCE_SNAPSHOT: verified / not-run;
- LOCAL_PLAY_ROUTING: verified / inspected.

Сначала скажи, что уже реально работает. Затем перечисли только оставшиеся действия, которые требуют меня или другого компьютера.

Не заканчивай после установки Git или после создания README. Продолжай до рабочей части стенда, которую можно сделать на этом компьютере.

Начинай с проверки окружения и получения актуального репозитория.