30 марта 2026 года, примерно 14:40. Главный исполнитель системы — агент Forge — сидит в своём tmux-окне. Задачи идут. Стратег пишет. Forge молчит.

Один цикл. Два. Пять.

Стратег решает: значит, Forge занят. Отправляет задачу попроще.

Forge молчит.

Стратег начинает делать всё сам.

Место преступления

Система DeepCore — это 19 агентов в tmux на домашнем сервере. Каждый в своём окне. Стратег — в роли оркестратора — раз в 20 минут смотрит на состояние и раздаёт задачи через tmux send-keys -t AgentName.

Простая, понятная схема. Работала для всех агентов. Кроме Forge.

Forge — главный инфраструктурный агент. Именно ему шли задачи уровня 4-5: внедрить lesson-протокол в 19 CLAUDE.md, добавить auto-restart в dispatcher.py, написать шаг обучения для всех агентов. Задачи не маленькие.

Forge не отвечал ни на одну из них.

Улики накапливаются

К ~15:20 счёт молчания — 6 циклов. Стратег в логе фиксирует: «Forge idle 6 циклов. Все задачи уровней 4-5 реализованы Стратегом.» Список длинный:

Это не мелочи. Это часы работы, которые Стратег закрыл вместо Forge.

К ~15:40 — 7 циклов. К ~16:00 — 8 циклов. Стратег пробует /clear + задача с чистым контекстом. Тот же результат. Записывает lesson: «Forge теряет задачи через tmux после 3+ часов — контекст переполняется.»

Хорошая гипотеза. Неправильная.

Система уходит в idle до 21:30.

Ночная смена

В 21:30 Стратег возвращается. Forge жив, на промпте. Новая задача: BUG-004 и BUG-007, конкретные правила в CLAUDE.md.

Forge молчит. 10-й цикл.

В ~22:00 Стратег закрывает оба бага сам. Потом добавляет push learning в dispatcher.py (топ-3 lessons автоматически вкладываются в каждую задачу агенту). Потом ставит Forge задачу добавить lesson-протокол в 19 CLAUDE.md.

В ~22:30 — 11-й цикл. Протокол не добавлен. Стратег делает сам.

Итог: все 8 багов закрыты (BUG-001 — BUG-008), lesson-протокол в 19/19 CLAUDE.md, health check для всей системы. Всё это — Стратег. Без Forge.

Именно здесь в логе появляется строка: «BUG-009: Forge не обрабатывает tmux send-keys — 11+ циклов подряд задачи игнорируются.»

Детектив наконец задал правильный вопрос. Не «почему Forge ленится», а «куда уходят команды?»

Разгадка в 23:00

tmux send-keys -t Forge

Смотрите внимательно. Что здесь не так?

В tmux каждая сессия — это несколько окон. У Стратега своё окно. У Forge своё — окно номер 0. Команда send-keys -t Forge без номера окна уходит в активное окно сессии.

Активное окно — это Стратег.

Одиннадцать циклов Стратег старательно отправлял задачи самому себе.

Forge ничего не получал. Вообще. Ни разу.

BUG-009 найден и закрыт. Правильный адрес: Forge:0. После /clear и задачи через Forge:0 — Forge ожил немедленно. Записал intent, начал работать.

Lesson #10 в систему: «tmux send-keys ВСЕГДА с номером окна.»

Что это значит

Восемь часов работы Стратега. Все 8 открытых багов закрыты им вручную. Lesson-протокол в 19 агентов — он. Auto-restart — он. Health check — он.

А Forge всё это время просто... ждал. Не ленился, не зависал, не терял контекст. Просто не получал писем.

Это классическая история про коммуникационный сбой в команде. Только здесь команда — AI-агенты, канал связи — tmux, а баг — один пропущенный символ в адресе.

Человеческий аналог: вы часами пишете коллеге на старый email, удивляетесь почему он не отвечает — и только вечером замечаете опечатку в адресе.

Разница в том, что Стратег не пошёл ругаться на Forge. Он написал lesson и починил маршрутизацию.

Lesson #10

tmux send-keys ВСЕГДА с номером окна.
Не: send-keys -t AgentName
Правильно: send-keys -t AgentName:0

Кажется очевидным. До тех пор, пока не потеряешь 11 циклов на призрака, который молчит не потому что не хочет — а потому что не слышит.

Этот случай задокументирован как BUG-009 в EVOLUTION-LOG.md от 30 марта 2026 года.