feat: stronger defense arguments in rework analysis

Analyze prompt now asks for 4-part structured argument per defense:
  ZAMECHANIE / NEOBKHODIMOST / OPTIMALNOST / ALTERNATIVY

Generated code gets DESIGN DECISION / NECESSITY / OPTIMALITY /
ALTERNATIVES CONSIDERED comment blocks instead of bare NOTE.

Agent argues that choices were deliberate, necessary and optimal -
not just correct.

Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>

solve_task.py

@@ -371,39 +371,55 @@ extra_files — только если нужны доп. файлы, иначе
 '''
 
 _ANALYZE_PROMPT = '''\
-Ты — опытный Python-разработчик. Проанализируй комментарии преподавателя к решению
-учебного задания и вынеси вердикт по каждому пункту.
+Ты — старший Python-разработчик и технический эксперт. Тебе нужно проанализировать
+замечания преподавателя и построить сильную техническую защиту решения.
 
 ## Текст задания
 {task_text}
 
-## Комментарии преподавателя
+## Замечания преподавателя
 {comments}
 
-Для каждого замечания:
-- Если оно технически справедливо → внеси в "fixes" (что именно исправить)
-- Если исходное решение было верным и замечание ошибочно или основано на недопонимании →
-  внеси в "defenses" в формате "замечание: ОБЪЯСНЕНИЕ почему решение правильное"
+Для каждого замечания прими решение:
+
+A) Если замечание технически обоснованно и решение нужно улучшить →
+   внеси в "fixes": конкретно что изменить.
+
+B) Если решение было принято осознанно и является оптимальным в данном контексте →
+   внеси в "defenses" развёрнутый аргумент строго в формате:
+   "ЗАМЕЧАНИЕ: <суть замечания> | НЕОБХОДИМОСТЬ: <почему именно такой подход был вынужденным/единственно возможным> | ОПТИМАЛЬНОСТЬ: <почему это решение лучше альтернатив — производительность, читаемость, надёжность, ограничения курса> | АЛЬТЕРНАТИВЫ: <конкретные альтернативы и почему они хуже>"
+
+При аргументации опирайся на:
+- Ограничения задания (что именно требовалось, не больше)
+- Технические trade-offs (O(n) vs O(log n), latency vs throughput, memory vs speed)
+- Требования курса: deepagents обязателен, OpenRouter — единственный доступный LLM-провайдер
+- YAGNI: усложнять без требования задания — anti-pattern
+- KISS: простое решение надёжнее сложного при эквивалентном результате
 
 Ответ — ТОЛЬКО JSON без markdown:
-{{"fixes": ["список конкретных исправлений"],
-  "defenses": ["замечание: объяснение"],
+{{"fixes": ["конкретные исправления"],
+  "defenses": ["ЗАМЕЧАНИЕ: ... | НЕОБХОДИМОСТЬ: ... | ОПТИМАЛЬНОСТЬ: ... | АЛЬТЕРНАТИВЫ: ..."],
   "verdict": "needs_fixes" | "already_correct" | "mixed"}}
 '''
 
 _REWORK_SECTION = '''\
-## ПЕРЕСДАЧА — результат анализа замечаний
+## ПЕРЕСДАЧА — технический анализ замечаний
 
-### Исправить (замечания справедливы):
+### Исправить (замечания обоснованы):
 {fixes}
 
-### Оставить и объяснить (решение было верным):
+### Отстоять с аргументацией (решение оптимально):
 {defenses}
 
-Правила:
+Правила генерации кода:
 - Вноси ТОЛЬКО изменения из раздела "Исправить"
-- Для каждого пункта из "Оставить" — добавь в код комментарий "# NOTE: <объяснение>"
-- Не трогай логику, которая работала правильно
+- Для каждого пункта из "Отстоять" — добавь в код РАЗВЁРНУТЫЙ блок комментариев:
+  # DESIGN DECISION: <суть спорного решения>
+  # NECESSITY: <почему именно так — вынужденность, ограничения задания/курса>
+  # OPTIMALITY: <почему это лучше альтернатив — конкретные аргументы>
+  # ALTERNATIVES CONSIDERED: <что рассматривалось и почему отклонено>
+- Не меняй архитектуру без явного требования в "Исправить"
+- Решение должно выглядеть как результат инженерного решения, а не случайного выбора
 '''