agent-control-center/agents/antigravity/inbox/2026-08-18-консолидация-рабочего-пространства.md

Консолидация проектов в единое рабочее пространство

• Кому: 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, ни в других копиях.

Метод, который работает:

# один свежий клон репозитория как эталон
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 после мержа, но коммит в репозитории остаётся:

gh api "repos/<owner>/<repo>/commits/<sha>" --jq .sha

Если оба способа говорят «нет» — работа существует только на этом диске.

Отдельно проверить, что удалённый репозиторий вообще существует: gh api repos/<owner>/<repo>. На основной машине нашлась папка с 163 файлами, чей remote отвечал 404 — репозитория не было вовсе.

3. Спасение

• Незапушенные ветки — запушить под их собственными именами. В main не пушить: приёмку делает главный агент.
• Код без существующего репозитория — создать приватный репозиторий (gh repo create <owner>/<name> --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 <owner> --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 (у владельца) — карту рабочего пространства. Если структура папок на этой машине окажется принципиально другой — не подгонять её под описание, а сообщить в отчёте.