ADR 0027: Узкая команда (человек + ассистент) и зрелость «для открытия» — две оси, не одна очередь¶

Статус: Accepted
Дата: 2026-04-08
Обновлено: 2026-04-08 — Accepted; discoverability и триггеры оси B. Подробности — § История.

Связанные ADR¶

ADR	Роль
0024	контракты и дисциплина границ без обещания SemVer «завтра»
0005	отложенный plugin-host
0013	discoverability — отдельная ось от скорости ядра
0010	TOML как честный слой конфигурации
0028	канон пути и формата пользовательского `settings.toml` и секретов
0029	TOML-first; целостный центр настроек deferred; точечный UI — фасад канона

Резюме¶

Две оси: границы узкой команды (человек + ассистент) vs очередь публичной зрелости.
Discoverability через доки, примеры и ADR — без обязательства «IDE для всех» в v1.

Вне ADR¶

Документ	Роль
README	политика: крупные смены направления — отдельным коммитом + ADR
onboarding-first-run-v1	живой чертёж first-run/онбординга — не обязательный объём для «открытия репо» по этому ADR; ориентир, когда осознанно углублять UI

Контекст¶

CascadeIDE целится в зрелую десктопную IDE, которую можно открыть для других разработчиков и интеграторов. Параллельно фактическая скорость разработки сейчас опирается на очень малую «команду»: автор(ы) плюс ассистент (LLM) в парной работе.

Без явного разделения возникает риск:

либо размазывания — делать «как для магазина» (онбординг, установщики внешних тулов, полированный UI настроек) и терять темп на ядре;
либо технического долга на границах — гнать фичи «только для себя» и потом переписывать контракты, пути конфигов и интеграции при первом внешнем потребителе.

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

Решение¶

Развести два независимых измерения — форма продукта и очередь поставки.

1. Ось A — «форма» (зрелость границ)¶

Инвестируем заранее в то, что дорого менять задним числом:

стабильные контракты расширения и протоколы (в духе 0024: слои, capabilities, out-of-proc интеграции);
одна точка правды для конфигурации (глобальный settings.toml, репозиторный workspace.toml и т.д. — см. 0010);
ADR и навигатор (architecture-policy.md) при смене направления — чтобы внешний читатель и будущий ты видели почему, а не только что в коде.

Это не обязательство сегодня делать полный онбординг или маркетинговую «упаковку»; это обязательство не ломать доверие к границам без осознанного шага.

2. Ось B — «очередь» (что в спринте у пары человек–ассистент)¶

Жёстко приоритизируем то, что даёт ценность текущим пользователям процесса (включая парную работу с ассистентом): отладка, редактор, диагностики, LSP, предсказуемые пути файлов.

В отложенный бэклог (см. триггеры ниже) относим типичные «магазинные» вещи, если они не разблокируют ядро:

отдельное приложение настроек, тяжёлый установщик внешних серверов из IDE, расширенный first-run wizard;
полировку discoverability ради незнакомого пользователя (0013 остаётся направлением, но не блокером скорости ядра).

Минимально достаточная discoverability для «открытия репозитория» на оси B: документация (в т.ч. по TOML и путям конфигов), примеры в репозитории, ADR с обоснованием решений — без возражений как базовый пакет v1; полноценный мастер в UI не требуется, пока не сработал триггер. Дополнительный ориентир по более богатому first-run/онбордингу (когда созреет очередь): чертёж onboarding-first-run-v1 — не часть минимума по этому ADR, а место для будущей проработки.

Триггеры: когда трогать отложенное по оси B¶

Поднимать задачи «для незнакомца» (мастера, установщики, сильная полировка discoverability) из отложенного бэклога осознанно, если выполняется хотя бы одно:

Первый внешний контрибьютор (не из круга текущих авторов репо) с реальным PR/issue — сигнал, что путь «клонировать и собрать» уже проверяется чужим контекстом.
Релиз-кандидат или иная явная веха «показываем сборку шире, чем себе» — появляется оправдание тратить время на трение входа.
Явная боль или запрос от пользователя/интегратора (в т.ч. повторяющийся) — не ждать «магазина», если уже горит.
Инфраструктурная необходимость — задача по оси B разблокирует ядро или тесты (тогда это не «только аудитория», а смешанный платёж; см. §3).

Пока ни один триггер не сработал, очередь остаётся на ядре и границах (оси A и «свои» пользователи).

3. Правило согласования осей¶

Если задача укрепляет границы (контракт, протокол, формат файла) — её можно брать раньше, даже при малой команде.
Если задача только снижает трение для незнакомца — брать после стабилизации ядра для «своих», либо когда сработал триггер из §2 (внешний контрибьютор, RC, явная боль, инфраструктурная необходимость).

4. Явная эвристика для обсуждения в чате / ревью¶

Вопрос к любой крупной работе: «Это платёж по оси A (границы) или по оси B (аудитория)?»
Если оба — разбить на два коммита/два подхода по смыслу (политика логических коммитов в корневых правилах репозитория Cursor).

Последствия¶

Планирование: в issue/заметках можно помечать метками в духе boundary vs audience-friction (имена — на усмотрение репо); не смешивать в одной фразе «надо успеть к открытию» без уточнения оси.
SDK и 0024: «малая команда» не освобождает от дисциплины контрактов; наоборот, контракты экономят время пары «человек + ассистент» на согласовании границ.
Открытие исходников и «IDE для других»: готовность измеряется не только количеством мастеров, а предсказуемостью конфигов, документированными решениями и тестируемыми границами — это совместимо с узкой командой, если очередь честна.

Отклонённые альтернативы¶

«Сначала только хак для себя, потом всё переложим под людей» — отклонено как источник дорогого переписывания на границах; оси A/B разделяют «быстро внутри» и «аккуратно снаружи» без отказа от второго.
«Зрелость = сейчас делаем UI для массового пользователя» — отклонено: смешивает оси и губит темп ядра при малой полосе пропускания.
«Пока нас двое — ADR не нужны» — отклонено: ADR как раз дешёвее для пары, чем устная память и расхождение контекста между сессиями ассистента.

История изменений¶

Дата	Изменение
2026-04-08	Accepted; уточнён минимум discoverability (дока + примеры + ADR, ссылка на чертёж онбординга); добавлены триггеры вывода задач оси B из отложенного бэклога.