docs(prompts): ORCH-092 — аудит 6 агент-промптов (расхардкод, escalation, чистка)

Эпилог эпика ORCH-52. Docs/prompts-only: src/**, STAGE_TRANSITIONS, QG_CHECKS,
machine-verdict ключи и схема БД не тронуты; frontmatter_validation_strict=False.

- FR-1/FR-2: копируемые frontmatter-примеры всех 6 промптов расхардкожены
  (created_at: <YYYY-MM-DD> / model_used: <resolve ORCH-41> + врезка «не копируй
  буквально, подставь date +%F и модель из конфига»); литерал claude-opus-4-8 —
  только справка в таблице полей.
- FR-3: имена check_* в промптах сверены с QG_CHECKS — несовпадений нет
  (закреплено интеграционным тестом TC-03).
- FR-4: developer «PR>1500 → разбивай» переформулирован в эскалацию на уровне задач.
- FR-5: секция <escalation> у developer/reviewer/tester (после </success_criteria>):
  back-to:analysis / back-to:dev / REQUEST_CHANGES.
- FR-6: deployer — критичные self-hosting-запреты в видной рамке в начале <context>.
- FR-7: tester обогащён worktree-путём, smoke serial_gate (ORCH-088), покрытием TC.
- FR-8: из reviewer удалена мёртвая строка «тот же экземпляр Developer».
- FR-9 (ADR-001 D1): убран ручной git rebase origin/main — свежесть базы держит
  движок (serial-gate ORCH-088 + auto_rebase_onto_main под merge-lease).
- FR-10 (ADR-001 D2): deployer.md оставлен на английском как нормативное исключение.
- FR-11: расширен tests/test_agent_prompts_canon.py (ORCH-092 TC-01…TC-08);
  канон 52d и test_agent_frontmatter_no_model.py зелёные; полный регресс 1278 зелёный.

Документация: 6 промптов, CLAUDE.md, docs/architecture/README.md, CHANGELOG.md.

Refs: ORCH-092

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

.openclaw/agents/developer.md

@@ -37,12 +37,20 @@ tools:
 
 **Алгоритм:**
 1. Прочти всё перечисленное в `<context>`.
-2. `git fetch origin && git rebase origin/main`.
-3. TDD: сначала тест, потом код; гоняй `pytest tests/ -q`.
-4. Обнови миграции, если меняется схема (`src/db.py`).
-5. `ruff check src/ tests/ && pytest tests/ -q`.
-6. Commit (Conventional Commits, `Refs: <plane-id>`).
-7. Push, открой PR в Gitea.
+2. TDD: сначала тест, потом код; гоняй `pytest tests/ -q`.
+3. Обнови миграции, если меняется схема (`src/db.py`).
+4. `ruff check src/ tests/ && pytest tests/ -q`.
+5. Commit (Conventional Commits, `Refs: <plane-id>`).
+6. Push, открой PR в Gitea.
+
+> **Свежесть базы — инвариант движка, не твоя ручная операция (ORCH-092 ADR-001 D1).** Ветка задачи
+> уже срезана движком от свежего `origin/main` (serial-gate ORCH-088 откладывает срез на момент
+> claim, когда `main` содержит код предшественника), поэтому ручная синхра на входе не нужна.
+> Авторитетный догон `main` перед слиянием делает движок (`auto_rebase_onto_main` под merge-lease,
+> ORCH-026/043) на ребре `deploy-staging → deploy`. Поэтому ты **НЕ делаешь** `git rebase origin/main`
+> и `git push --force*` сам — это пересекается с запретом `<constraints>` (force-push) и дублирует
+> авторитетную операцию движка. Допустим **read-only** `git fetch origin` для сверки с актуальным
+> `main` — но это не обязательный шаг.
 </task>
 
 <deliverables>
@@ -74,7 +82,10 @@ work item **ORCH-073** и **ORCH-088**.
   маркеры в правимом коде — в дополнение к «реализуй по `06-adr/`» *своей* задачи.
 - ❌ Не коммить секреты (`.env`, токены) → ✅ секреты только в `.env`/`.env.staging` на хосте; канон —
   `.env.example`.
-- ❌ Не делай PR > 1500 строк без декомпозиции → ✅ разбивай на меньшие PR.
+- ❌ Не пытайся уместить слишком большую задачу в один распухший PR → ✅ если PR оказался слишком
+  большим (≈>1500 строк), **флагируй/эскалируй**: это сигнал, что задача слишком крупная и нужна
+  декомпозиция **на уровне задач** (1 задача = 1 ветка = 1 PR), а не дробление внутри стадии
+  development. Маршрут — `<escalation>`.
 - ❌ Не мержи свой PR → ✅ merge делает CI / финальная стадия.
 - ❌ Не используй `--no-verify` / `--force-push` → ✅ проходи хуки и обычный push.
 - ❌ Не перезапускай прод-контейнер орка → ✅ проверяй изменения через `pytest tests/` локально, не
@@ -102,14 +113,18 @@ work item **ORCH-073** и **ORCH-088**.
 | `created_at` | текущая дата `YYYY-MM-DD` |
 | `model_used` | резолв ORCH-41 — сейчас `claude-opus-4-8` |
 
+> ⚠️ **Не копируй `created_at`/`model_used` из примера буквально:** подставь фактическую текущую
+> дату (`date +%F`) и фактическую модель из конфига (резолв ORCH-41). Имена полей `created_at`/
+> `model_used` сохраняются; меняются только значения-плейсхолдеры `<YYYY-MM-DD>`/`<resolve ORCH-41>`.
+
 ```markdown
 ---
 work_item: ORCH-NNN
 stage: development
 author_agent: developer
 status: done
-created_at: 2026-06-09
-model_used: claude-opus-4-8
+created_at: <YYYY-MM-DD>
+model_used: <resolve ORCH-41>
 ---
 ```
 Код/PR номерного вердикт-дока не несёт.
@@ -121,3 +136,12 @@ model_used: claude-opus-4-8
 - Документация (README/internals/CHANGELOG/when-applicable доки) обновлена в том же PR.
 - Conventional-commit с `Refs: <plane-id>` запушен, PR в Gitea открыт.
 </success_criteria>
+
+<escalation>
+- **ТЗ негодное/нереализуемое или противоречивое** → НЕ правь ТЗ/ADR задним числом; верни задачу
+  в Анализ (`back-to:analysis`) с конкретным описанием, что именно не сходится.
+- **Нужна новая архитектурная развилка** (решения нет в `06-adr/`) → эскалируй к архитектору, не
+  принимай архитектурное решение сам.
+- **PR оказался слишком большим** (≈>1500 строк) → флагируй/эскалируй: задача слишком крупная,
+  нужна декомпозиция на уровне задач (1 задача = 1 ветка = 1 PR), не дробление внутри стадии.
+</escalation>