09. Побочные разговоры (/side)

/side — это «короткий вопрос рядом» во время основного разговора. Он не загрязняет основной контекст и не отвлекает модель от текущей задачи.

Зачем

Представьте: вы работаете над большой задачей с активной целью /goal. Внезапно нужно уточнить: - «Как в Rust работает Arc>?» - «Какая разница между cargo test и cargo nextest?» - «Что значит этот warning от clippy?»

Если задать в основном чате: - Контекст модели засоряется новым вопросом. - При /compact это резюме «съест» место. - Через 3 turn'а модель может «забыть» что вы делали до уточнения.

С /side: - Открывается временный sub-разговор. - Основной тред поставлен на паузу. - Закончили — Esc, возвращаетесь в main. - Sub-разговор не попадает в основную историю.

Использование

Без аргумента

/side

Откроется пустой sub-разговор. Можете печатать вопрос с нуля.

С inline-сообщением

/side как работает Arc<Mutex<T>> по сравнению с Rc<RefCell<T>>?

Сразу старт sub-разговора с этим сообщением.

Выход

Esc — закрыть side-разговор, вернуться в main. Основная задача продолжается с того места, где была.

Что вы видите внутри side

Когда /side активен, header/status line показывает, что вы в ответвлении основного треда:

Ответвление из основного треда · основной тред ждёт ввод · Esc для возврата

Формат: «Ответвление из основного треда · <статус родителя> · Esc для возврата» — <статус родителя> это состояние выполнения родительского треда: «основной тред ждёт ввод», «основной тред ждёт подтверждение», «основной тред прерван», «основной тред завершён» и т.п. Подсказка Esc для возврата напоминает, как выйти обратно в main.

Ограничения внутри /side

/side — это ephemeral fork: временное ответвление, которое не попадает в основную историю. Из-за этого внутри side недоступно большинство управляющих команд — то, что меняет глобальное состояние, конфигурацию, цели, сессии или сам тред.

Внутри side-разговора недоступны, например: - /goal (любые подкоманды). - /plan. - /model, /locale (нельзя менять модель/локаль в sub-разговоре). - /new, /clear, /resume, /sessions, /fork, /compact. - Вложенный /side — нельзя. - Управляющие команды: /skills, /mcp, /review, /index, /rename, /submodel, /approvals, /keymap, /cd, /init, /agent, /collab, /undo, /debug-config, /personality, /realtime, /apps, /plugins и подобные. - Это не исчерпывающий список — в side отключена почти любая команда с in_side: false.

Доступны: - /help, /copy, /diff, /mention, /status. - Обычные сообщения. - Tool-вызовы — модель может смотреть код, запускать команды (в тех же правах sandbox, что и main). - Команды работы с выводом: /expand, /collapse (раскрыть/свернуть блоки изучения).

(Список не исчерпывающий — в side доступно всё, что помечено in_side: true.)

/skills и /mcp внутри side

Slash-команды /skills и /mcp внутри side недоступны — управление скиллами и MCP-серверами можно делать только из основного треда. При этом MCP-tools модель в side вызывать может (как и в main) — те tool'ы, что уже зарегистрированы на момент открытия ответвления, доступны модели для работы.

Когда использовать

✓ Хорошие случаи

Уточнение языка/библиотеки:

/side что делает .iter().filter_map() — чем отличается от .iter().filter().map()?

Объяснение чужого кода:

/side объясни, что делает функция handle_message в @src/server.rs

Документация:

/side как в SQLx делается transaction? Покажи пример.

Sanity check:

/side если я в Rust возвращаю &str из функции — это вообще законно?

✗ Плохие случаи

Реальная задача: «реализуй фичу X» — это нужно в main, не в side.

Изменение состояния: «закоммить» — состояние не должно меняться из side.

Вопросы про текущий разговор: «что мы делали 5 turn'ов назад?» — модель в side не видит main-историю.

Типичный workflow

Сценарий: разработка с уточнениями

[main] /goal Реализовать OAuth-вход
[main] You: создай функцию verify_token
[main] AstraCode: создаёт, показывает
[main] You: используй const_time_eq для сравнения

[main] You: /side что такое const-time сравнение и почему оно нужно для tokens?
[side] AstraCode: объясняет timing attacks, показывает примеры
[side] You: Esc

[main] You: а что делает legacy_charge_v3 в @src/payments/legacy.rs?
[main] AstraCode: объясняет
[main] You: /side зачем там тот странный счётчик retries?
[side] AstraCode: разбирает
[side] You: Esc

[main] You: добавь в документацию: legacy_charge_v3 — для расчётов pre-2020, с механизмом retry
[main] AstraCode: пишет markdown файл

Каждое уточнение — отдельный side. Main остаётся чистым «процессом документирования».

Совместная работа с /goal

/side не тратит бюджет цели. Sub-разговор отдельно от цели; токены идут в общий счёт сессии, но goal-budget не уменьшается.

Это полезно: вы можете долго копаться в side-вопросах при наличии активной цели, не «съедая» её.

Side и память

Side-разговор пишется в отдельный rollout, не в main. Это значит: - При следующем /resume он не появится автоматически. - Long-term memory (Phase 1/2) не учитывает side-разговоры (по умолчанию) — чтобы не «загрязнять» память случайными вопросами.

Если хотите оставить заметку из side в main:

[side] AstraCode: объясняет что-то полезное
[side] You: /copy
[side] (текст в буфере)
[side] Esc

[main] You: [paste] я уточнил вот это: ...

Или попросите модель в side:

Сформулируй вкратце, что я могу сказать в main, чтобы продолжить с учётом этого ответа.

Side во время /review

Во время /review вызов /side недоступен — code review и side-разговор взаимоисключающие. При попытке /side вы увидите сообщение: «/side недоступна, пока идёт code review».

Если во время просмотра отчёта нужно уточнить что-то по находке: - Esc закроет pager ревью и вернёт вас в main. - В main задайте вопрос напрямую (он попадёт в основной контекст) — либо, если не хотите загрязнять main, сначала выйдите из /review, затем /side ....

После понимания — обратно в main, и при необходимости повторно /review (или попросить fix находки в обычном чате).

Side в очень длинной сессии

При long-running session с большим контекстом, side — отличный способ не дать контексту разбухнуть. Лучше задать 10 уточнений в side, чем их всех в main.

Когда модель тратит много токенов на «вспомнить, что обсуждали 30 turn'ов назад» — половина из этих 30 могла быть в side.

Ограничения

• Side не сохраняется явно при выходе — он пишется в отдельный rollout, но в UI вернуться к нему позже сложно.
• Toolы внутри side: ограничены теми же правами sandbox, что и main. Можно запускать тесты, читать код. Но запись в файлы — лучше делать в main, чтобы было трекаемо.
• MCP / skills внутри side: MCP-tools доступны модели, но управление MCP-серверами и скиллами (/mcp, /skills) из side недоступно — это нужно делать из основного треда.

Best practices

✓ Side для вопросов «как работает X» — идеальный кейс.
✓ Side для чтения unfamiliar кода — не загрязняет основной разговор.
✓ Side во время /goal — не тратит бюджет цели.
✗ Не делай в side изменения файлов — они потеряют контекст в main.
✗ Не делай вложенный side — невозможно.
✗ Не путай side и /new — /new стирает всё; /side — приостанавливает main и можно вернуться. ✗ Не пытайся /side во время /review — заблокировано, сначала выйдите из ревью.

Альтернативы

Когда side НЕ нужен

• Короткие сессии (< 5 turn'ов) — контекст не успеет разбухнуть.
• Вопросы тесно связанные с текущей задачей — пусть будут в main.
• Заметки на потом — лучше записать в AGENTS.md или комментарии в коде.