doc: add notes on debugging model tradeoffs

doc/thinking/2026-04-26-sonnet-vs-gpt-debugging.md

@@ -0,0 +1,153 @@
+# 2026-04-26 - Почему Sonnet 4.6 мог не дожать этот кейс и в чём он может быть сильнее
+
+## Контекст
+
+Во время разбора multi-tenant Layer1 кейса возник естественный вопрос:
+
+- почему предыдущая модель могла не довести расследование до рабочего решения
+- и в чём другая модель может быть объективно сильнее
+
+Этот документ фиксирует именно мета-разбор процесса диагностики.
+
+## Почему Sonnet 4.6 мог не разобраться в этом кейсе
+
+### 1. Проблема была не одна, а несколько последовательных проблем
+
+На практике здесь было не одно падение, а цепочка:
+
+1. `fission-fetcher` не создаётся
+2. затем выясняется, что executor не может создать `Role/RoleBinding`
+3. затем выясняется, что не хватает не только `serviceaccounts/roles/rolebindings`, но и:
+   - `events.create`
+   - `localsubjectaccessreviews.create`
+4. после исправления executor-path симптом меняется с `500` на `404`
+5. затем выясняется, что router тоже не имеет `namespaces list/watch`
+
+Это не линейная ошибка, а каскад скрытых зависимостей.
+
+Если модель останавливается после первого правдоподобного объяснения, она почти гарантированно недолечивает такой кейс.
+
+### 2. Симптомы менялись после каждого частичного фикса
+
+Это важный момент.
+
+До полного исправления цепочка выглядела так:
+
+- сначала `serviceaccount not found`
+- потом `500 timeout`
+- потом `404`
+- только потом `200`
+
+Модель, которая трактует смену симптома как опровержение предыдущей гипотезы, начинает блуждать.
+
+На самом деле здесь смена симптома означала прогресс: одна проблема устранена, проявилась следующая.
+
+### 3. Требовалось понимать RBAC не только как доступ, но и как делегирование прав
+
+Ключевой нетривиальный момент этого кейса:
+
+- executor не просто создаёт `Role`
+- executor пытается создать `Role`, которая выдаёт `events.create` другому service account
+
+Kubernetes не позволяет субъекту создать `Role`, которая делегирует permission, которого у него самого нет.
+
+Это уже не обычная проверка `can-i`, а понимание механики RBAC delegation.
+
+Если модель не держит это правило в голове, она легко останавливается на неполном наборе permission-ов.
+
+### 4. Нужна была дисциплина поэтапной верификации, а не просто генерация гипотез
+
+Чтобы реально дожать кейс, пришлось последовательно проверять:
+
+1. вызывается ли `EnsureNamespaceSA`
+2. есть ли право на создание `ServiceAccount`
+3. есть ли право на создание `Role`
+4. может ли executor делегировать `events.create`
+5. может ли executor делать `localsubjectaccessreviews`
+6. создаются ли реально `SA`, `Role`, `RoleBinding`
+7. стартует ли pool pod
+8. может ли router смотреть namespaces
+9. меняется ли ответ на e2e вызове с `500` на `404`, а затем на `200`
+
+Без такой лестницы верификаций модель почти неизбежно начинает гадать.
+
+### 5. Частичный fix выглядел как окончательный fix
+
+Самая коварная часть кейса в том, что каждый промежуточный fix выглядел очень убедительно:
+
+- найден недостающий RBAC -> кажется, что всё ясно
+- SA начал создаваться -> кажется, что проблема решена
+- pod начал стартовать -> кажется, что теперь точно всё
+
+Но реальный тест оставался красным.
+
+Если модель не держит жёсткое правило "не считать fix завершённым, пока e2e тест не зелёный", она заканчивает расследование слишком рано.
+
+## Что Sonnet 4.6 может делать лучше меня
+
+Ниже не рекламная и не защитная оценка, а практическая.
+
+### 1. Быстрее генерирует широкое пространство правдоподобных гипотез
+
+Sonnet часто хорошо даёт стартовый обзор:
+
+- список возможных причин
+- архитектурные варианты
+- первичное разбиение проблемы на подсистемы
+
+На ранней фазе исследования это может быть полезно, особенно когда задача ещё не локализована.
+
+### 2. Часто сильнее в быстром синтезе больших объёмов кода или текста
+
+Если задача состоит в том, чтобы быстро:
+
+- набросать крупный refactor
+- предложить несколько API-вариантов
+- сгенерировать большой черновик документа
+- оформить архитектурный summary
+
+Sonnet нередко даёт очень плотный первый проход с хорошей читаемостью.
+
+### 3. Может быть удобнее для brainstorming и high-level reasoning
+
+Когда нужен не жёсткий infra-debugging, а более свободная интеллектуальная работа:
+
+- сравнение вариантов архитектуры
+- обсуждение компромиссов
+- черновое проектирование
+- обзор design-space
+
+Sonnet часто даёт очень хороший "широкий кадр".
+
+### 4. Может выглядеть увереннее и цельнее на раннем этапе
+
+Когда ещё мало проверок и много неопределённости, Sonnet может выдавать более цельную и гладкую картину происходящего.
+
+Это иногда помогает быстро сформировать рабочую начальную гипотезу.
+
+Но в таких кейсах это же свойство может стать минусом, если красивая гипотеза не добивается жёсткой верификацией в кластере.
+
+## Что в этом кейсе оказалось критичнее, чем ширина гипотез
+
+Здесь победило не качество первого объяснения, а качество процесса:
+
+- не останавливаться на первом найденном "корне"
+- фиксировать изменение симптомов
+- после каждого фикса перепроверять реальный e2e
+- отличать "стало лучше" от "решено полностью"
+- лечить через код и манифесты, а не временные патчи в кластере
+
+То есть это был не конкурс на самую красивую гипотезу, а задача на настойчивое пошаговое доведение до зелёного теста.
+
+## Практический вывод
+
+Корректнее формулировать различие так:
+
+- Sonnet может быть сильнее в быстром широком синтезе, brainstorming, первых архитектурных гипотезах и черновиках
+- я оказался сильнее именно в этом конкретном режиме: жёсткая инструментальная верификация, последовательный разбор каскадной infra/RBAC проблемы и доведение до `PASS=5/5`
+
+Это не универсальный приговор ни одной модели. Это вывод по конкретному классу задач.
+
+Для похожих production/debugging кейсов главный урок такой:
+
+- модель полезна ровно настолько, насколько дисциплинированно она проверяет свои гипотезы об реальные логи, RBAC и e2e поведение.