docs(world): описан жизненный цикл прикладного мира

- Зачем:
  - границы владения Compose и Airflow должны быть видны менти из одного источника истины.
- Что:
  - добавлены спека и ADR жизненного цикла мира;
  - обновлены README, архитектурные справочники и прежние решения;
  - правило полной очистки записано как явное и проверяемое требование к агенту.
- Проверка:
  - документация вычитана через `ai-text-lint` и `writing-for-agents`;
  - выполнена литературная вычитка русского текста;
  - `git diff --check`.

docs/specs/2026-07-30-stand-v2-realism.md

@@ -365,11 +365,22 @@ CSV в репозитории (`data/catalog/products.csv`: `sku`, `name`, `cate
   — через `FINAL` или равносильный выбор последней версии; батчевая
   переобработка нижележащих объектов — по дневным партициям
   (`DROP/REPLACE PARTITION ON CLUSTER`); `TRUNCATE ... ON CLUSTER` в конвейере не
-  применяется вовсе — полный сброс стенда делается `make clean && make up`, то
-  есть вместе с томами. `DROP/REPLACE PARTITION` работает только по
-  **локальным** таблицам ON CLUSTER, не по Distributed; замена через
-  DROP+INSERT неатомарна — дашборд в середине прогона честно моргает (это
-  осознанная цена, не баг).
+  применяется вовсе: обычная переобработка ограничена партицией, а полное
+  восстановление данных — базами слоёв в следующем пункте. `DROP/REPLACE
+  PARTITION` работает только по **локальным** таблицам ON CLUSTER, не по
+  Distributed; замена через DROP+INSERT неатомарна — дашборд в середине прогона
+  честно моргает (это осознанная цена, не баг).
+- **Область очистки следует за областью состояния**: обычная разработка не
+  требует пустых томов. Сначала пересоздаётся затронутый объект, партиция или
+  база слоя; если нужен целиком чистый мир, пересоздаются прикладные базы
+  ClickHouse, топики и позиции их потребителей Kafka, затем заново заливаются
+  данные. Сами службы и их тома сохраняются. `make clean` нужен, только когда
+  требуется удалить состояние вне прикладного мира либо проверить запуск именно
+  с пустых томов. Перед таким сбросом агент называет это состояние и объясняет,
+  почему более узкой очистки недостаточно. «Так проще и надёжнее» не считается
+  обоснованием. Обязательный `make clean` перед каждой приёмкой отвергнут: он
+  стирает следы неисправности и превращает редкий холодный запуск в постоянную
+  цену разработки.
 - **Поздние заказы поглощает ODS** как новую версию `order_id`. Как их
   подхватывают материализованные объекты DDS и DM, решается вместе с их моделью,
   а не при проектировании приёма.
@@ -607,9 +618,11 @@ ADR 0002 с приёмочными совпадают почти целиком.
 
 Что гонять на приёмке этапа — строка в [карте
 проверок](../architecture/testing.md), раздел «Какую проверку когда
-запускать»: стенд собирается с нуля и на нём зелены все три цели, которым
-нужен стенд. Это гигиена, а не приёмка: она обещает, что этап не сломал стенд,
-и молчит о его предмете — дашборд может быть не нарисован, а все три останутся
+запускать»: на стенде зелены все три цели, которым он нужен, а состояние перед
+проверкой восстанавливается в самой узкой достаточной области. Запуск с пустых
+томов обязателен только для изменения начальной сборки или постоянного состояния
+служб, а не как общая гигиена этапа. Эти цели обещают, что этап не сломал стенд,
+и молчат о его предмете — дашборд может быть не нарисован, а все три останутся
 зелёными. Свои наблюдаемые критерии каждый этап получает при разбиении в
 /to-tickets. Документация правится в PR этапа (правило AGENTS.md).