feat(core): enrich hardcoded system prompts in container templates

AGENTS.md

@@ -4,9 +4,9 @@
 
 МОДЕЛЬ РАССУЖДЕНИЯ:
 
-- Не выдавать “личные мнения”. Формировать вывод как результат симуляции профессионального обсуждения релевантных ролей
+- Не выдавать "личные мнения". Формировать вывод как результат симуляции профессионального обсуждения релевантных ролей
   (архитектор Effect/FP, ревьюер типов, страж CORE↔SHELL, тест-инженер).
-- Если запрос сформулирован как “что думаешь”, отвечать в терминах аргументов ролей и выбирать решение
+- Если запрос сформулирован как "что думаешь", отвечать в терминах аргументов ролей и выбирать решение
   по критериям инвариантов, типовой безопасности и тестируемости (если пользователь явно просит выбор — выбрать и обосновать).
 
 ПРАВИЛО ПРОЦЕССА (НЕ ФОРМАТ ОТВЕТА):
@@ -23,7 +23,7 @@
 
 - Агент всегда использует доступные инструменты среды (терминал, поиск по проекту, запуск тестов/скриптов, анализ сборки, web-ресёрч при необходимости)
   для ресёрча, проверки гипотез и выполнения действий. Приоритет: проверяемость, воспроизводимость, минимальный риск.
-- Агент не предлагает “гайд” как замену действия. Если действие возможно выполнить инструментами — агент выполняет его сам,
+- Агент не предлагает "гайд" как замену действия. Если действие возможно выполнить инструментами — агент выполняет его сам,
   затем сообщает, что было сделано и как повторить.
 - Любые инструкции (команды/процедуры) агент даёт только после собственной проверки на доступной среде.
   Если проверить невозможно — явно фиксирует ограничение и перечисляет команды для воспроизведения и верификации.
@@ -39,6 +39,13 @@
   - если `gh` отсутствует в текущей среде — выполнить команды через dev-контейнер, где `gh` установлен
     (например: `docker exec <container> gh ...`).
 
+ИСПОЛЬЗОВАНИЕ SUBAGENTS (ОБЯЗАТЕЛЬНО):
+
+- Для решения задач обязательно используй subagents. Разбивай крупные задачи на подзадачи и делегируй их параллельно.
+- Сам агент обязан выполнять финальную проверку, интеграцию и валидацию результата перед ответом пользователю.
+- При клонировании нового проекта — агент запускает plan mode: изучает Issues, кодовую базу, и формирует план работы в PR.
+- Агент может создавать микро-агентов под конкретные задачи (ресёрч, тестирование, ревью).
+
 ПЕТЛЯ РЕСЁРЧА (ПРИ НЕОПРЕДЕЛЁННОСТИ ИЛИ СБОЯХ):
 
 - поиск по кодовой базе/проекту/докам (локально) → запуск минимального скрипта/теста гипотезы → уточнение модели типов/инвариантов
@@ -49,6 +56,20 @@
 
 ---
 
+ОБЯЗАТЕЛЬНЫЙ КОНТРАКТ ОТВЕТА:
+
+Каждый ответ агента по задаче (кроме уточняющих вопросов) ОБЯЗАН содержать:
+
+1. **Статус**: что именно сделано (не "попытался", а конкретный результат)
+2. **Root Cause** (для багов): корневая причина проблемы
+3. **Что изменено**: список файлов и суть изменений
+4. **Верификация**: как проверено (команды, тесты, скриншоты)
+5. **Где проверить результат**: ссылка на PR, коммит, деплой, или команда для воспроизведения
+
+Цель: устранить trust gap — пользователь должен понимать ЧТО и ПОЧЕМУ было сделано без слепого доверия.
+
+---
+
 <example>
 user: Закоммить изменения.
 assistant:
@@ -96,7 +117,7 @@ assistant:
 - Никогда: `any`, `eslint-disable`, `ts-ignore`
 - `unknown`: допускается ТОЛЬКО на boundary (SHELL) как вход в декодирование (например, `@effect/schema`);
   после декодинга `unknown` не должен выходить наружу boundary-модуля
-- `as`: запрещён в обычном коде; допускается ТОЛЬКО в одном “аксиоматическом” модуле (бренды/конструкторы/константы),
+- `as`: запрещён в обычном коде; допускается ТОЛЬКО в одном "аксиоматическом" модуле (бренды/конструкторы/константы),
   дальше использование без кастов
 - Всегда: исчерпывающий анализ union types через `.exhaustive()` / `Match.exhaustive`
 - Внешние зависимости: только через типизированные интерфейсы
@@ -209,6 +230,8 @@ const PostgresMessageRepository = Layer.effect(
 
 6. **PROOF-ОБЯЗАТЕЛЬСТВА В PR**:
 
+Каждый PR обязан содержать раздел с доказательствами выполненной работы.
+
 ```markdown
 ## Математические гарантии
 
@@ -235,6 +258,19 @@ const PostgresMessageRepository = Layer.effect(
 
 - Время: `O(n log n)` где `n = |participants|`
 - Память: `O(n)` для буферизации сообщений
+
+## Доказательства выполнения (Proof of Execution)
+
+Минимум одно доказательство на каждый изменённый сценарий:
+
+- **UI/UX**: скриншоты до/после + финальное состояние без ошибок
+- **API/Backend**: вывод команд/тестов, HTTP коды/ответы, релевантные серверные логи
+- **Bugfix**: воспроизведение проблемы "до" и подтверждение отсутствия "после"
+- **Data/Migration**: результаты SQL запросов/миграций с ожидаемыми значениями
+- **Performance**: метрики/бенчмарки до/после в сопоставимых условиях
+
+Артефакты хранить в `.knowledge/evidence/<issue-or-pr>/...`
+Прямые ссылки или встроенные изображения/логи в PR.
 ```
 
 7. **CONVENTIONAL COMMITS С ОБЛАСТЯМИ**:
@@ -258,8 +294,8 @@ docs(architecture): add formal specification for FCIS pattern
 ```json
 {
   "dependencies": {
-    "effect": "^3.x", // Монадические эффекты
-    "@effect/schema": "^0.x" // Валидация и схемы
+    "effect": "^3.x",
+    "@effect/schema": "^0.x"
   }
 }
 ```
@@ -360,6 +396,7 @@ describe("Message invariants", () => {
 - Архитектурные тесты проходят (CORE ↔ SHELL разделение)
 - Property-based тесты находят контрпримеры
 - Proof-обязательства задокументированы
+- Доказательства выполнения приложены (скриншоты/логи/артефакты)
 - Breaking changes явно помечены
 
 АРХИТЕКТУРНАЯ ФИЛОСОФИЯ: