Control-Archaeology Refactor

В долго живущем AI-инструменте накапливаются режимы. Каждая новая фича приземляется как тоггл, свитч или icon-button рядом с предыдущими. Через несколько кварталов в левой панели пять перекрывающихся мод, выбираемых тремя разными типами контролов, со взаимной исключённостью через скрытие соседей. Только методом проб и ошибок пользователь разберётся в этих режимах. Поверхности нужны раскопки, а не ещё одна кнопка.

На что смотреть

• Один компонент >~3,000 LOC, владеющий поверхностью.
• Моды выбираются смешанными типами контролов (Switch + icon button + carousel + tab) в одной control-bar.
• Взаимная исключённость через скрытие — включение моды A скрывает контролы моды B, и пользователь не видит, что теряет.
• Админские тогглы занимают визуальное место у не-админов.
• Discovery моды требует читать код или спрашивать у внутреннего пользователя.

Если истинно три и больше — поверхности нужен рефактор.

Механизм

1. Перечислить все моды, которые поддерживает поверхность. Пометить, что user-visible, что admin-only, что dead code.
2. Сгруппировать моды по отношениям. У большинства поверхностей есть одна primary-ось (что я делаю?) и ноль или больше secondary-осей (как я это делаю?). Primary-ось становится top-tab-навигацией; secondary-оси остаются in-panel как нормальные sub-контролы под активным табом.
3. Поднять primary-ось в top-tab-навигацию. Табы по дизайну взаимно исключают друг друга, видны всегда и подписывают себя. Discovery моды решён лейблами табов.
4. Выкинуть мёртвые тогглы. Provider/prompt-model-тогглы, админ-флаги, A/B-свитчи с явным победителем — всё прочь. Диф — часть победы.
5. Перекомпоновать внутри каждого таба вокруг естественного потока. Если у таба есть шаговая последовательность (например, persona → voice → video), раскладываем её как hero-flow, а не как параллельные контролы.

Почему это работает

Исходная control-bar пытается быть всеми осями сразу. Рефактор разделяет оси по иерархии: табы держат primary-выбор, панель — его последствия. У каждого слоя одна работа. Пользователь отвечает на «в какой я моде?» за ноль секунд (читает таб) вместо трёх (аудит состояний тогглов).

Пример — поверхность генерации аватаров

Реальный рефактор: один компонент, 7,113 LOC, владел пятью перекрывающимися модами — collaborative, campaign, separate-vs-mixed-контроль, edit, voice. Каждая переключалась своим типом контрола. Provider- и prompt-model-тогглы занимали визуальное место у не-админов.

После раскопок:

• Верхние табы: Generate · Campaign · Edit (Appearance) · Voice. Primary-ось вышла на поверхность.
• Выкинуто: provider/prompt-model-тогглы (админские), Separate-vs-Mixed (оставлен merged-only, который и так выиграл).
• Voice перекомпонован: пайплайн audio → video разложен как hero-flow, а не как параллельные тогглы.

Та же функциональность. Половина когнитивной нагрузки. Discovery моды теперь — побочный эффект простого взгляда на экран.

Pitfalls

• Переименование табов в то же, что было у старых тогглов. Если лейблы табов слово-в-слово повторяют старые свитчи, возвращающийся пользователь не заметит изменения. Новые имена.
• Расползание числа табов. Пять табов — уже много. Если доходишь до семи — поверхность на самом деле две поверхности в одном пальто; разделяй.
• Stateful tab persistence. Помнить последний активный таб на пользователя обычно правильно; помнить его глобально — нет. Скопить persistence к сущности (этот конкретный аватар, его последний таб — а не «таб аватаров вообще»).