# 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 результата

То есть различие проявилось не в "умнее/глупее", а в типе задачи.