К содержанию
Содействиебиблиотека
XСравнение исследованийX03-0203 · Раздел 03

Сопоставление отчетов волны октября 2026 с материалами NotebookLM и легаси (часть 4)

Обновлён
10.11.2026
Редактор
gemini-3.8
Источников
2
Утверждений
69
Объём
14 971 из 15 000 знаков
На странице
  1. Сопоставление отчетов волны октября 2026 с материалами NotebookLM и легаси — часть 4 из 11
  2. Утверждения темы
  3. Фрагменты корпуса темы
  4. [LG-193-F020] — LG-193, фрагмент 02, строки 21-97, тема «assistant»
  5. assistant
  6. [LG-193-F022] — LG-193, фрагмент 02, строки 102-124, тема «assistant»
  7. assistant
  8. [LG-193-F032] — LG-193, фрагмент 04, строки 7-10, тема «assistant»
  9. assistant
  10. [LG-193-F034] — LG-193, фрагмент 04, строки 81-84, тема «user»
  11. user
  12. [LG-193-F035] — LG-193, фрагмент 04, строки 85-88, тема «assistant»
  13. assistant
  14. [LG-193-F036] — LG-193, фрагмент 04, строки 89-126, тема «assistant»
  15. assistant
  16. [NB-S04-F002] — NB-S04, фрагмент 01, строки 9-10, тема «Tab 1»
  17. Tab 1

Сопоставление отчетов волны октября 2026 с материалами NotebookLM и легаси — часть 4 из 11

Назначение и границы: Документ входит в блок X библиотеки материалов «Содействие» (Гомель). Тематический охват: Сопоставление отчетов волны октября 2026 с материалами NotebookLM и легаси. Ответственная линия: корпус. Статус материала: есть проверенные пруфы — фрагментов 102, утверждений 539, проверенных 13.

Утверждения темы

Фрагменты корпуса темы

[LG-193-F020] — LG-193, фрагмент 02, строки 21-97, тема «assistant»

assistant

Посмотрел. У нас уже есть и Git, и ветки, и worktree. Главная проблема — раздробленность управления: код, инструкции, навыки и состояние задач живут в разных местах, а общий шаблон сильно привязан к OpenCode. Просто перенести его в Orca — значит перенести и значительную часть этой сложности.

Ничего не менял.

Как устроена старая оркестрация

Это не один навык, а целая система:

  • project-orchestration-setup устанавливает и синхронизирует шаблон.
  • .opencode/agents/ содержит профили исполнителей.
  • orchestrator-main выбирает исполнителей, модели и ограничения параллельности.
  • orchestration-core.md задаёт порядок работы и отчётности.
  • Проектные skills добавляют предметные правила.
  • Настройки моделей находятся отдельно от Markdown-профилей.

В обоих проектах 28 файлов профилей, совпадающих по именам с текущим каноном. При этом сам установочный навык продолжает описывать 27 — уже есть расхождение документации и структуры.

Координатору предписано использовать встроенный task OpenCode. Лимиты семейств агентов описаны текстом; наличие этих инструкций само по себе не доказывает, что среда технически ограничивает параллельность.

Фактическое устройство проектов

ObsyncConfdeck
Папка управления/cloud/drive/projects/obsync/cloud/drive/projects/confdeck.ru
Git этой папки30 коммитов, отдельная историяНи одного коммита, 0 отслеживаемых файлов
Рабочий код/work/code/obsync/work/code/confdeck-next
Текущая ветка кодаrefactor/landing-test-1.10.3.8rebuild/typescript
Ветки / рабочие папки кода8 / 452 / 15
Незакоммиченная работаОсновная папка чистая; EN — 158 записей измененийnext — 12; ещё две рабочие папки — 6 и 26

Это локальная проверка. GitHub не обновлял через fetch: ahead 22 у Confdeck означает отставание последней локально известной удалённой ветки, а не проверенное состояние сервера сейчас.

Что здесь действительно мешает

  1. Confdeck содержит противоречивые указатели на исходники.
    README правильно направляет в confdeck-next, а проектный навык оркестрации объявляет главным code/, который ведёт в старый Laravel-проект. Агент может добросовестно прочитать инструкции и выбрать неправильную реализацию.

  2. Документы Confdeck пока не защищены историей Git этой папки.
    Планы, состояние пересборки и правила существуют на диске, но локальные коммиты кода их не сохраняют. Это не означает отсутствия других резервных копий — именно Git-истории здесь нет.

  3. У Obsync два набора проектных навыков.
    В папке управления — 23 навыка, в коде .agents/skills — ещё 11 каталогов навыков. Это разные наборы, не ссылки на один источник. При этом связь уже частично сделана: AGENTS.md в коде явно отправляет агента читать папку управления. Поэтому уточняю предыдущий ответ: проблема не в полном отсутствии связи, а в неодинаковом автоматическом обнаружении и зависимости от чтения переходных инструкций.

  4. Worktree используются, но их жизненный цикл не завершён.
    У Confdeck много сохранённых рабочих папок, включая незакоммиченную работу. Некоторые вершины веток не входят в историю rebuild/typescript напрямую. Это не доказывает потерю изменений: их могли перенести отдельными коммитами. Поэтому удалять такие папки по признаку «старые» нельзя.

  5. Отчётность стала самостоятельным большим массивом.
    У Obsync — 4051 файл в reports, 703 в agent-prompts, 460 в agent-pings. У Confdeck — 896 промптов и 766 пингов. Это исторические накопления, не доказательство бесполезности каждого файла, но агенту трудно отличить актуальное решение от старого. Более того, README Obsync описывает запись промптов для LONG-задач, а общий core требует её для всех задач.

  6. Git исторически использовали преимущественно как резервное сохранение.
    Это прямо закреплено в документации Obsync. Система строилась вокруг текущих файлов и отчётов, а не обязательной цепочки «задача → ветка → проверенный коммит → объединение». Поэтому количество веток само по себе не даёт ясной картины принятой работы.

Что я бы сохранил для Orca

Предметные навыки Obsync, продуктовые контракты Confdeck, инструкции запуска и выпуска, ограничения по данным, критерии проверки и полезную историю решений.

Что не стоит переносить целиком

Старый набор из 28 профилей, привязки к семействам моделей, обязательную цепочку OpenCode task, запись каждого межагентского промпта отдельным файлом и многослойные повторения правил.

Для этих двух проектов я бы не начинал с физического объединения папок. Сначала нужен короткий и однозначный паспорт каждого проекта: актуальный код, базовая ветка, документы, навыки, запуск, проверка и выпуск. Затем — разобраться с незакоммиченной работой и существующими worktree. После этого Orca может управлять терминалами и заданиями поверх уже понятной структуры.

Мой вывод: полезные знания в старой системе есть. Неудачную оркестрационную механику можно заменить, сохранив эти знания и историю — без пересоздания проектов с нуля.

<oai-mem-citation> <citation_entries> MEMORY.md:256-256|note=[Historical Confdeck roots checked against current Git worktrees] MEMORY.md:677-677|note=[Distinction between scaffold synchronization and protected model bindings] </citation_entries> <rollout_ids> 01a102d0-ee73-7091-afd2-72fa7155b93f 01a0ce44-1a79-7a21-9a3e-06eac31f94e7 </rollout_ids> </oai-mem-citation>

[LG-193-F022] — LG-193, фрагмент 02, строки 102-124, тема «assistant»

assistant

Да, это разумный следующий шаг: сделать Git-репозиторий полноценным переносимым проектом, который можно открыть в Orca, локальном агенте или облачной среде. При этом «собрать с нуля» я бы понимал как чистую организацию существующего продукта, а не переписывание рабочего кода.

Предлагаю такую схему:

  • Один приватный репозиторий на продукт: актуальный код, документация, проектные навыки, инструкции запуска и проверки. Без зависимости от абсолютных путей твоего компьютера.
  • Общие правила плюс короткие инструкции для разных агентов. Нужные проекту навыки доступны внутри репозитория; установленный на твоём ПК Home не должен быть обязательным условием работы.
  • Воспроизводимое окружение: образцы настроек без секретов, понятные команды установки, запуска и тестов. Облачный агент должен понимать, что способен проверить самостоятельно.
  • Основная ветка — принятый результат. Каждая задача выполняется в отдельной ветке; локально параллельным агентам выдаются worktree, облачные работают в своих копиях.
  • Результат агента — PR: что изменено, что проверено, что осталось. Один ответственный за интеграцию проверяет изменения и объединяет их последовательно.
  • Деплой — отдельный шаг. Слияние кода не должно случайно запускать изменения production.

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

С браузерными сервисами нужно проверить возможности каждого конкретного продукта и тарифа: подключение репозитория, выполнение команд, отправку веток и создание PR. Наличие чата с моделью ещё не означает, что он умеет отправлять код в GitHub. Где прямой интеграции нет, можно принимать изменения патчем и оформлять их отдельной веткой локально.

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

Я бы первым переносил Obsync, ограничившись организацией репозитория. Confdeck сложнее: там незавершённая пересборка, множество веток и несколько папок с несохранённой работой.

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

[LG-193-F032] — LG-193, фрагмент 04, строки 7-10, тема «assistant»

assistant

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

[LG-193-F034] — LG-193, фрагмент 04, строки 81-84, тема «user»

user

вопрос теперь (вернемся к вопросу) почему орка ругнулась на гит, как у нас установлен гит, как агенты его используют

[LG-193-F035] — LG-193, фрагмент 04, строки 85-88, тема «assistant»

assistant

Проверю установленный Git и настройки автора: откуда агенты берут имя и почту и почему Orca не смогла создать проект. Ничего менять не буду.

[LG-193-F036] — LG-193, фрагмент 04, строки 89-126, тема «assistant»

assistant

Orca ругнулась потому, что Git установлен, но для новых проектов не задан автор коммитов. Это не ошибка прокси и не проблема входа в GitHub.

Сейчас проверил:

ГдеНастройки автора
Общие настройки пользователяИмя и email не заданы
Код ObsyncЛокально указан Obsync Team и email
Документы ObsyncАвтор не задан
ConfdeckЛокально указаны Pavel Udalov и email

Поэтому в существующем репозитории Obsync агент может создавать коммиты, а при создании нового проекта Orca обнаруживает отсутствие автора и останавливается.

Как установлен Git

У тебя обычный системный Git из пакета CachyOS/Arch: версия 2.56.0, программа /usr/bin/git. Переустанавливать его не нужно.

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

Как его используют агенты

Локальный агент запускает команды Git в папке проекта — так же, как ты в терминале:

  • смотрит изменения;
  • выбирает файлы для коммита;
  • создаёт коммит;
  • отправляет коммиты на GitHub, если есть доступ и соответствующая задача.

VS Code, Orca и терминалы могут работать с одним репозиторием. Отдельная история для каждого приложения не создаётся. Если два агента работают в одной папке, они видят общие изменения и могут мешать друг другу. Для одновременной работы нужны отдельные рабочие папки — например, Git worktrees.

В браузерной среде у агента уже своя копия репозитория, свой Git и свои настройки автора. С твоим компьютером она обменивается изменениями через GitHub.

Имя автора и доступ к GitHub — разные вещи. Имя/email подписывают коммит; ключ или токен разрешает отправку. Настройка автора не авторизует агента в твоём аккаунте.

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

[NB-S04-F002] — NB-S04, фрагмент 01, строки 9-10, тема «Tab 1»

Tab 1