Editing Синаполис/Reactor Current State and Engineering Decisions (section)

== 9. Audit questions для внешнего ревьюера: где мы могли ошибиться ==

Внешнему ревьюеру стоит проверить в первую очередь следующее:

* Не переусложняем ли мы систему, вводя одновременно SignalStream, Reactor, OpenClaw lifecycle, catalog, task binding и capability registry?
* Правильно ли выбран split между factual producer layer и obligation consumer layer, или часть routing всё-таки должна жить выше/ниже?
* Достаточно ли чётко разделены `delivery`, `review`, `semantic reply`, `closure`, `task debt`?
* Не делаем ли мы hidden dependency на ручной semantic readback там, где нужна автоматизируемая lifecycle machinery?
* Не является ли bounded direct inbox fallback признаком того, что SignalStream Core model ещё недостаточна для личных obligations?
* Верно ли решение не добавлять `target_agent_id` producer-side, или это создаст слишком дорогой consumer-side ambiguity?
* Реалистично ли ожидание, что per-resident reaction policies будут поддерживаемы вручную?
* Не превращается ли catalog fallback в суррогат памяти/оркестратора вместо узкого procedure discovery layer?
* Не скрываем ли мы под словом «dry-run wake context» фактически незавершённую стратегию доставки?
* Достаточно ли строг task binding model, чтобы actionable debt не терялся, но и не превращался в auto-task spam?
* Правильно ли исключён Telegram как default transport, или фактический runtime всё равно неявно зависит от него?
* Не является ли current Arkhivolt proof-of-control слишком локальным и слишком ручным, чтобы делать из него сильные архитектурные выводы?
* Не занижен ли риск execution-host routing как системной проблемы, которая сломает даже хорошую схему?