# Консолидация проектов в единое рабочее пространство - **Кому:** antigravity - **Дата:** 2026-08-18 - **От кого:** владелец проекта (через Claude) - **Ветка:** `antigravity/workspace-consolidation` - **Файл отчёта:** `../done/2026-08-18-консолидация-рабочего-пространства.md` ## Зачем это делается На машине владельца проекты расползлись: десятки клонов одного репозитория в разных папках, задания и отчёты агентов вперемешку с бинарниками, и часть работы существовала только на диске — ни в одном репозитории её не было. Найти, кто что сделал, было нельзя. На основной машине разбор уже выполнен. Нужно сделать то же самое на этой. Результат: один каталог `Agent_projects` с клонами всех репозиториев, единая структура `agents/` внутри каждого, и ничего ценного за пределами git. ## Что нужно сделать Порядок обязателен: сначала опись, потом спасение, и только потом уборка. Обратный порядок уничтожает данные. ### 1. Опись Найти все папки проектов: домашний каталог пользователя, `~/projects`, рабочий стол, и любые другие места, где агенты создавали клоны. Для каждой папки записать: git это или нет, remote, текущая ветка, число незакоммиченных изменений, число файлов. Опись сохранить в отчёт целиком. Она — доказательство, что ничего не пропущено. ### 2. Проверка, что работа есть на GitHub Для **каждой** папки с git проверить **все локальные ветки**, а не только текущую. Одной проверки HEAD недостаточно: в брошенных клонах лежат ветки, которых нет ни на GitHub, ни в других копиях. Метод, который работает: ```bash # один свежий клон репозитория как эталон git fetch origin '+refs/heads/*:refs/remotes/origin/*' git rev-list --remotes | sort -u > /tmp/remote-shas.txt # в каждой проверяемой папке git for-each-ref refs/heads --format='%(objectname) %(refname:short)' ``` Тип ветки, чей tip отсутствует в списке, проверить вторым способом — ветка могла быть удалена на GitHub после мержа, но коммит в репозитории остаётся: ```bash gh api "repos///commits/" --jq .sha ``` Если оба способа говорят «нет» — работа существует только на этом диске. Отдельно проверить, что удалённый репозиторий вообще существует: `gh api repos//`. На основной машине нашлась папка с 163 файлами, чей remote отвечал 404 — репозитория не было вовсе. ### 3. Спасение - **Незапушенные ветки** — запушить под их собственными именами. В `main` не пушить: приёмку делает главный агент. - **Код без существующего репозитория** — создать приватный репозиторий (`gh repo create / --private`) и залить туда все ветки. Перед заливкой проверить на секреты: `.env`, `*.pem`, `*.key`, присвоения вида `TOKEN=...`, и убедиться, что `.gitignore` закрывает `.venv` и `.env`. - **Незакоммиченные правки** — сохранить патчем `git diff HEAD > имя.patch` в `agents/<агент>/notes/salvage-<дата>/` того проекта, к которому они относятся. Неотслеживаемые файлы скопировать туда же, кроме мусора (`.venv`, `node_modules`, `*.exe`, `*.zip`). - Прежде чем считать правки ценными, посмотреть на них. На основной машине папка с 3870 «изменениями» оказалась сломанным индексом: `git rm` без коммита, содержимое совпадает с GitHub. Спасать там было нечего. ### 4. Клоны и структура agents/ Склонировать все репозитории владельца в `Agent_projects` (список — `gh repo list --limit 100`). В каждом создать: ``` agents/ README.md TASK-TEMPLATE.md REPORT-TEMPLATE.md claude/ codex/ antigravity/ hermes/ grok/ opencode/ inbox/ done/ notes/ (в каждой .gitkeep) _accepted/ ``` Тексты `README.md` и шаблонов взять из любого уже разобранного репозитория — они одинаковы во всех. В `AGENTS.md` дописать раздел со ссылкой на `agents/README.md`; если `AGENTS.md` нет — создать. ### 5. Раскладка заданий и отчётов Папки с заданиями и отчётами агентов разложить по `agents/` нужного проекта. Агента определять по имени файла или пути: `antigravity`, `codex`, `hermes`, `claude`/`клод`, `grok`, `opencode`. Файлы со словом `task`/`задач` — в `inbox/`, остальные — в `done/`. Что не опознаётся — в `agents/_salvage-<дата>/`, разбирается вручную потом. Тяжёлое в git не класть. Архивы, инсталляторы, бинарники и файлы больше 5 МБ — в `Agent_projects/_archive/<дата>/`, наборы данных — в `Agent_projects/_data/`. Обе папки вне репозиториев. ### 6. Уборка Папки, чьё содержимое доказано лежит на GitHub, переместить в `_trash_<дата>/` рядом с домашним каталогом. **Не удалять.** Удаление — решение владельца, он сотрёт карантин сам, когда проверит. ### 7. Публикация В каждом репозитории — ветка `chore/agents-workspace`, один коммит структуры, второй коммит разбора, PR. В `main` не мержить. ## Границы - Ничего не удалять безвозвратно. Только карантин. - Не пушить в `main` и не мержить PR. - Не трогать клоны чужих репозиториев (владелец != владелец проектов), даже если в них есть локальные правки. Записать их в отчёт и оставить на месте. - Не трогать пользовательские файлы: фотографии, книги, документы, бэкапы. - Не менять глобальный `git config`. Подпись ставить локально в репозитории, ту же, что в истории коммитов (`git log --format='%an <%ae>'`). ## Что здесь ломается Проверено на основной машине, повторится и тут: - **Длинные пути Windows.** Cherry-pick и checkout падают с `Filename too long`. Лечится `git config core.longpaths true` и коротким путём рабочей копии. - **Занятые файлы.** Часть папок не переместится: их держит работающий процесс другого агента. Это не ошибка — записать в отчёт и оставить. - **Чужая работа в той же копии.** В клоне может параллельно работать другой агент: проверять `git branch --show-current` перед каждым коммитом, иначе свой коммит ляжет на чужую ветку. Если это уже случилось — переносить коммит через `git worktree`, а не переключать ветку под чужой работой. - **CRLF.** При `core.autocrlf=true` рабочая копия получает CRLF, в git уходит LF. Проверять надо содержимое коммита, а не файл на диске. - **Валидаторы документации.** В `business-platform` есть `node scripts/check-docs.mjs`: он считает все `.md` в репозитории и требует обновления статистики после добавления файлов (`node scripts/check-docs.mjs --write-stats`). Прогнать до коммита. - **Ветка по умолчанию.** Не везде `main`; у части репозиториев `master`. PR создавать с явным `--base`. ## Как проверить результат Считается сделанным, когда одновременно: 1. `Agent_projects` содержит клоны всех репозиториев владельца, у каждого `agents/` с полным набором папок; 2. для каждой папки из описи в отчёте сказано, что с ней стало: перенесена, в карантине, оставлена и почему; 3. ни одна ветка ни в одной папке не осталась незапушенной — доказать повторным прогоном проверки из пункта 2 и приложить её вывод; 4. в каждом репозитории открыт PR, `main` не тронут; 5. карантин на месте, ничего не удалено. ## Контекст Как выглядит результат на основной машине — в этом же репозитории: `agents/README.md` описывает схему, `Agent_projects/README.md` (у владельца) — карту рабочего пространства. Если структура папок на этой машине окажется принципиально другой — не подгонять её под описание, а сообщить в отчёте.