auto-sync: 2026-06-08 16:10:01

memory/2026-06-08.md

@@ -270,3 +270,10 @@
   - FR-5 (защита навсегда): пост-деплой регресс-гард — sanity main, alert если код ранее-merged задач откатился.
   - AC-9: воспроизведение на staging — 2 задачи с CHANGELOG-правкой доезжают без потери кода друг друга.
 - ⚠️ Особый риск: ORCH-73 чинит САМ merge-verify → деплой через который она едет. Нужна осторожность на её собственном Confirm Deploy (могут всплыть переходные эффекты). Следить.
+
+## ✅ ORCH-73 BRD APPROVED (16:04 MSK) → architecture (run_id=381)
+- Проверила BRD(8к)/ТЗ(11к)/AC(6к) — эталон. Аналитик УТОЧНИЛ мой git-аудит точнее: дефект не в branch_is_behind_main (та проверка корректна), а в OR-ветке pr_already_merged внутри verify_merged_to_main (~стр.649), засчитывающей docs-PR. G1 (восстановление) отмечен как уже сделанный через restore-PR #76.
+- ТЗ: FR-1 verify ТОЛЬКО по SHA-предок-main; FR-2 pr_already_merged → idempotency-guard (вариант б); FR-3 merge реально сливает code-PR; FR-4 .gitattributes CHANGELOG merge=union (с предупреждением: union только append-only!); FR-5 регресс-гард ALERT+HOLD. Схема БД/QG/API не трогаются. never-raise/kill-switch/non-self везде.
+- AC: 11 критериев. AC-2 (verify True только SHA-в-main даже при docs-PR), AC-3 (воспроизведение бага 067/069→HOLD+alert), AC-4 (.gitattributes+check-attr+тест 2 ребейзов), AC-5 (регресс-гард), AC-7 (идемпотентность по SHA), AC-10 (НАВСЕГДА: 2 задачи с CHANGELOG на staging без потерь), AC-11 (self-hosting safety).
+- Approved → architect (job 507, run_id=381). Идёт автономно.
+- Логи орка теперь в MSK ✅ (16:04).