rules: add Task Critical Assessment (TCA) to prevent waste

Add task-critical-assessment.md with 5 criteria to evaluate tasks BEFORE execution:
1. Abstraction over local API → reject (MCP lesson)
2. Layer without proven need → reject (hybrid fallback lesson)
3. Environment more complex than task → reject (Docker overlay lesson)
4. No acceptance criteria → require clarification
5. Previously rolled back work → require justification

Link from global.md so every agent runs TCA before starting work.

Prevents repeating the MCP incident: 6 commits, 1700+ lines, 2 days → full revert.

.kilo/rules/global.md

@@ -54,7 +54,20 @@ Always verify generated frontmatter with: `node scripts/validate-agents.cjs`
 - Subagents MUST NOT invoke the `task` tool to spawn further subagents
 - Orchestrator (`mode: all`) is the ONLY agent allowed to use `task` tool
 
-### Bash Hardening
+## Task Critical Assessment
+
+Before executing any user request, apply the criteria from `task-critical-assessment.md`.
+
+If any criterion triggers → STOP and ask for clarification.
+
+Key checks:
+1. Is this an abstraction over an already-local API?
+2. Does it add layers without a proven failure mode?
+3. Is the environment more complex than the task itself?
+4. Are there clear acceptance criteria with measurable outcomes?
+5. Has this (or something similar) been rolled back before?
+
+## Bash Hardening
 - Default bash permission for agents: `ask` (not `allow`)
 - Agents that REQUIRE shell execution for their core function MAY have `bash: "allow"` with explicit justification:
   - `lead-developer`: build, test, and tooling commands

.kilo/rules/task-critical-assessment.md

@@ -0,0 +1,94 @@
+# Task Critical Assessment (TCA)
+
+Оценка целесообразности задачи ДО начала выполнения.
+
+## Проблема
+
+Мы тратили время и токены на:
+- MCP Gitea интеграцию (6 коммитов, 1700+ строк) — откат через 2 дня
+- Docker overlay networking для локального API
+- Multi-layer fallback цепочки, которые никогда не использовались
+- Документацию и E2E тесты для кода, который не пошёл в прод
+
+Каждая из этих идей казалась разумной на момент запроса.
+Ни одна не выдержала проверку реальностью.
+
+## Критерии отсева (Любой совпадение → STOP)
+
+### 1. Абстракция поверх локального API
+- Новый сервис/контейнер/протокол для доступа к тому, что уже доступно напрямую
+- **Пример**: MCP сервер для Gitea API, который мы и так вызываем через REST
+- **Вердикт**: Отказ. Используем существующий клиент напрямую.
+
+### 2. Слой без чёткой необходимости
+- "Давайте добавим X на случай если..."
+- Нет конкретного сценария, где текущее решение не работает
+- **Пример**: Hybrid клиент (MCP → REST → curl fallback) при рабочем REST
+- **Вердикт**: Отказ. Решаем реальную проблему, когда она появится.
+
+### 3. Окружение сложнее задачи
+- Docker + healthcheck + network + env vars для решения, которое делается в 3 строки кода
+- **Пример**: Docker контейнер для stdio MCP процесса
+- **Вердикт**: Отказ. Если решение не вмещается в существующую архитектуру — задача плохо сформулирована.
+
+### 4. Нет acceptance criteria
+- "Сделай лучше" / "Улучши" / "Оптимизируй"
+- Что измеримо изменится? Какой метрикой проверим результат?
+- **Вердикт**: Уточнить критерии. Если не уточняются — отказ.
+
+### 5. Повторение того, что уже было откачено
+- Если похожая задача уже была сделана и откачена — объяснить почему и предложить альтернативу
+- **Вердикт**: Требуется явное объяснение "что изменилось с прошлого раза"
+
+## Процедура оценки
+
+На каждый новый запрос:
+
+```
+1. Определить: что меняется для пользователя?
+   - Если ответ "ничего, это внутренняя архитектура" → критичнее оценивать
+
+2. Сколько слоёв добавляется?
+   - Agent → X → Y → Z → Gitea   (слишком много)
+   - Agent → GiteaClient → HTTP     (правильно)
+
+3. Какой Plan B если это не сработает?
+   - Если Plan B = "откатить всё" → это плохой Plan A
+   - Хорошая задача: можно отключить одной строкой или env var
+
+4. Оценка трудозатрат:
+   - < 30 мин и < 500 токенов: можно
+   - > 2 часа или > 3000 токенов: требуется явное подтверждение
+   - > 1 дня: milestone + обоснование
+
+5. Вопрос пользователю:
+   "Это добавит N слоёв. Сейчас работает через curl/fetch за 1 запрос.
+    Подтверди, что выигрыш стоит затрат."
+```
+
+## Формулировка отказа
+
+```
+Оценка задачи: [название]
+
+Вердикт: ❌ Не целесообразно
+
+Причина:
+- [критерий из списка выше]
+- [конкретное объяснение]
+
+Альтернатива:
+- [простое решение, которое уже работает]
+- [или: уточни acceptance criteria]
+
+Если подтверждаешь — выполню, но фиксирую сомнения.
+```
+
+## Исторические примеры "коллективной чуши"
+
+| Задача | Затраты | Результат | Критерий |
+|--------|---------|-----------|----------|
+| MCP Gitea интеграция | 6 коммитов, 1700 строк, Docker, healthchecks | Откат через 2 дня | Абстракция поверх локального API |
+| SSE transport для MCP | stdio bridge, JSON-RPC | Не поддерживается инфраструктурой | Слой без необходимости |
+| Hybrid fallback curl | MCP → REST → bash curl | Ни разу не сработал REST fallback | Слой без необходимости |
+| Docker network overlay | ipam subnet 172.28.0.0/16 | Конфликт с хостом | Окружение сложнее задачи |