doc: record debugging comparison notes

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

@@ -0,0 +1,115 @@
+# 2026-04-26 - Почему Sonnet 4.6 мог застрять на Layer1 и в чём он может быть сильнее
+
+## Зачем этот документ
+
+После успешного завершения кейса возник мета-вопрос:
+
+- почему другая модель могла не дойти до рабочего решения
+- в чём она всё же может быть объективно лучше
+
+Документ нужен как заметка о процессе расследования, а не о самом кодовом fix.
+
+## Почему Sonnet 4.6 мог не дожать именно этот кейс
+
+### Кейс был каскадным
+
+Здесь не было одного простого корня.
+
+Последовательность была такой:
+
+1. отсутствует `fission-fetcher`
+2. потом выясняется недостаток прав на `Role/RoleBinding`
+3. потом выясняется, что не хватает ещё и делегируемых permission-ов (`events.create`)
+4. потом выясняется, что не хватает `localsubjectaccessreviews.create`
+5. потом executor-path становится рабочим, но router-path всё ещё сломан
+6. затем обнаруживается отсутствие namespace watch/list у `fission-router`
+
+Модель, которая мыслит в режиме "нашёл корень -> исправил -> готово", на таком сценарии часто останавливается слишком рано.
+
+### Симптомы менялись и маскировали прогресс
+
+Промежуточные симптомы были:
+
+- `serviceaccount not found`
+- `500 timeout`
+- `404`
+- `200`
+
+Это классический случай, где изменение симптома означает не провал, а смену активного bottleneck.
+
+Если интерпретировать это неправильно, расследование начинает метаться.
+
+### Нужно было понимать RBAC delegation, а не только RBAC access
+
+Ключевая тонкость кейса:
+
+- executor создаёт `Role` для fetcher
+- эта `Role` выдаёт `events.create`
+- Kubernetes запрещает создавать `Role`, делегирующую permission, которого нет у самого вызывающего субъекта
+
+Следовательно надо было догадаться, что executor обязан получить `events.create`, хотя сам код падал не на "events usage", а на создании `Role`.
+
+Это не самый очевидный вывод без жёсткой опоры на лог и знание RBAC semantics.
+
+### Нужен был именно инструментальный debugging loop
+
+Решение появилось не после одной сильной гипотезы, а после цикла:
+
+1. найти симптом
+2. проверить конкретное право
+3. воспроизвести в новом namespace
+4. подтвердить создание реальных объектов
+5. перезапустить e2e test
+6. перейти к следующему симптому
+
+Без этого модель легко даёт хорошее объяснение, но не доводит задачу до зелёного результата.
+
+## Что Sonnet 4.6 может делать лучше меня
+
+### 1. Быстрый широкий синтез
+
+Sonnet часто хорошо работает на старте, когда нужно быстро:
+
+- разложить проблему по подсистемам
+- набросать несколько гипотез
+- предложить архитектурные альтернативы
+- собрать большой черновик текста
+
+### 2. High-level проектирование и brainstorming
+
+На задачах вида:
+
+- "какую архитектуру выбрать"
+- "какие trade-off у подходов"
+- "как разложить крупный рефактор"
+
+он может давать очень сильный первый проход.
+
+### 3. Большие гладкие черновики
+
+Для первых версий:
+
+- design-doc
+- proposal
+- API draft
+- architecture summary
+
+Sonnet нередко удобен именно скоростью и связностью первой версии.
+
+## Что оказалось важнее в этом кейсе
+
+В этом расследовании решающим было не качество первого explanation, а жёсткость процесса:
+
+- не верить первому найденному root cause
+- валидировать каждый шаг через cluster state
+- считать fix завершённым только после `PASS=5/5`
+- вносить изменения в код/манифесты, а не лечить кластер временными patch-командами
+
+## Итоговая формулировка
+
+Корректно говорить так:
+
+- Sonnet может быть сильнее в широком синтезе, brainstorming, архитектурных черновиках и быстрых первых гипотезах
+- в этом конкретном кейсе я оказался сильнее в последовательной инструментальной диагностике, удержании нескольких меняющихся симптомов и доведении расследования до рабочего e2e результата
+
+То есть различие проявилось не в "умнее/глупее", а в типе задачи.