type: standard
layer: arch
object: rebuild
aspect: operation
form: text
title: "Операция ПЕРЕСБОРКА"
status: active
version: 1.0.0
date: 2026-04-11
knowledge_level: У1
parent: arch-document-system.md
Стандарт описывает системную операцию реорганизации документов платформы: когда применять, три формата по масштабу, четыре служебных файла и порядок их заполнения, финализация.
При любом запуске пересборки (/rebuild, /rebuild restart, /rebuild start) — AI проходит блок выяснения и показывает меню. Без него не начинать.
1. Читаем REBUILD.md — есть зоны проекта и прогресс?
2. Читаем JOURNAL.md — есть записи? (последние 10)
3. Смотрим реальную структуру папок — что создано?
По результату — два пути:
┌─ БЛОК ВЫЯСНЕНИЯ ──────────────────────────────┐
│ 1. REBUILD.md — зоны, прогресс │
│ 2. JOURNAL.md — последние 10 записей │
│ 3. Реальная структура папок │
└───────────────────────────────────────────────┘
│
├─ есть прогресс + JOURNAL ──→ МЕНЮ ПРОДОЛЖЕНИЯ (§0.2а)
│
└─ нет прогресса / нет файлов → МЕНЮ НОВОЙ ПЕРЕСБОРКИ (§0.2б)
ШАГ А — блок выяснения (§0.0) — самостоятельно, без вопросов
ШАГ Б — показать меню (§0.2а или §0.2б) в зависимости от результата
ШАГ В — получить выбор → перейти к соответствующему режиму
══════════════════════════════════════════════════════
ПЕРЕСБОРКА — Продолжение
══════════════════════════════════════════════════════
ГДЕ ОСТАНОВИЛИСЬ
Прогресс: {N}% — {кратко что сделано}
Цикл: {текущий цикл}
Следующий шаг: {из JOURNAL.md}
ПРОСТРАНСТВА
┌─────────────────┬──────────────────────────────────────┐
│ Пересобираем │ {путь} ({N файлов, статус %}) │
│ Доп. инфо │ {путь} (только читать) │
│ Финал │ {путь} (после утверждения) │
└─────────────────┴──────────────────────────────────────┘
РЕЖИМЫ
1. ПРОДОЛЖИТЬ — с текущей позиции
2. КОРРЕКЦИЯ — просмотреть текущее, внести правки
3. РЕСТАРТ — архивировать, начать с нуля
4. ПРОВЕРКА — пройти по матрице, без изменений
══════════════════════════════════════════════════════
══════════════════════════════════════════════════════
ПЕРЕСБОРКА — Новая
══════════════════════════════════════════════════════
Прогресс не найден. Запускаем с нуля.
ШАГ 1 — определить границы:
Что пересобираем? → {папка / компонент / слой}
Один файл или весь компонент?
ШАГ 2 — собрать все документы по теме:
→ поиск по всей платформе
→ карта: что есть / устарело / отсутствует
ШАГ 3 — план документов → показать оператору → одобрение
ШАГ 4 — выполнение (по одному документу)
══════════════════════════════════════════════════════
Уточните:
1. ЧТО пересобираем? → путь к папке/теме
2. ГДЕ доп. инфо? → источники (только читать)
3. КУДА финальный результат? → путь назначения
══════════════════════════════════════════════════════
Правило: без ответов на 3 вопроса новая пересборка не начинается.
После выбора режима — AI задаёт уточняющие вопросы если есть неопределённость:
| Ситуация | Вопрос |
|---|---|
| Зоны не найдены в REBUILD.md | "Не нашёл таблицу зон. Укажите: что пересобираем / откуда берём доп. инфо / куда финал?" |
| Доп. источники не указаны | "Есть ли дополнительные папки для справки, кроме {найденных}?" |
| Неясны границы | "Пересобираем только {папка} или включая вложенные компоненты?" |
| Конфликт зон (одна папка = и источник и результат) | "Папка {X} указана и как источник и как результат. Режим: на месте или в отдельную папку?" |
Правило: не более 2 уточняющих вопросов за раз. Остальное — по ходу работы.
Если REBUILD.md и JOURNAL.md не найдены:
══════════════════════════════════════════════════════
ПЕРЕСБОРКА — Новый проект
══════════════════════════════════════════════════════
Служебные файлы не найдены. Запускаем с нуля.
Для старта нужно определить пространства:
1. ЧТО пересобираем? → путь к папке/проекту
2. ГДЕ доп. инфо? → путь к источникам (только читать)
3. КУДА финальный результат? → путь назначения
4. ЧТО не трогать? → исключения
══════════════════════════════════════════════════════
Без ответов на эти 4 вопроса — пересборка не начинается.
ПЕРЕСБОРКА — системная операция реорганизации документов с сохранением всего содержимого и применением актуальных правил платформы.
Когда нужна:
- Стандарты изменились — старые документы им не соответствуют
- Папка выросла — стала трудночитаемой, темы перемешались
- Проект завершён — нужно извлечь знания в arch/
Что гарантирует:
- Ничего не теряется без явного подтверждения оператора
- Каждый старый файл замаплен в новый
- Результат проверен по матрице из 8 критериев перед финализацией
Системный термин: ПЕРЕСБОРКА — не переименование и не удаление. Это управляемая трансформация с историей решений.
Два похожих, но разных сценария:
| Критерий | РАЗБОР (INTAKE) | ПЕРЕСБОРКА (REBUILD) |
|---|---|---|
| Что на входе | Чужие/внешние материалы | Существующие документы платформы |
| Цель | Создать новые документы из сырья | Реорганизовать уже существующее |
| Исходные файлы | Сохраняются в _source/ |
Маппятся в новые через SOURCES.md |
| Стандарты | Применяются при создании | Применяются к уже написанному |
| Потеря данных | Не актуально (из сырья) | Исключена — маппинг каждого файла |
| Результат | Новые документы платформы | Те же документы + актуальная структура |
| Служебные файлы | SOURCES.md, FACTS.md | REBUILD.md, JOURNAL.md, FACTS.md |
| Стандарт | arch-intake-operation.md | этот документ |
Когда РАЗБОР: "разбери это ТЗ", "создай проект из этих материалов", загрузка внешних данных.
Когда ПЕРЕСБОРКА: "стандарты изменились", "реорганизуй arch/", "папка устарела".
Граница: если файлы уже на платформе → ПЕРЕСБОРКА. Если файлы пришли извне → РАЗБОР.
Правило показа результатов: после каждого этапа AI показывает оператору список созданного с объяснениями и ждёт подтверждения перед переходом к следующему этапу.
После SOURCES.md:
→ показать: список файлов, карту тем, топ-дубли
→ обсудить: что пропустили? что удивило?
После FACTS.md:
→ показать: подтверждённые факты, закрытые конфликты
→ обсудить: все ли конфликты закрыты?
После REBUILD.md:
→ показать: новую структуру, граф зависимостей, маппинг
→ обсудить: структура верна? порядок правильный?
После каждого нового документа:
→ показать: что написано, откуда взято
→ обсудить: всё ли верно, нужны ли правки?
Финализация — только после явного "да" оператора.
При каждой пересборке явно указываются два типа материала — это разные роли:
| Роль | Термин | Что это | Как используется |
|---|---|---|---|
| Первичный материал | ИСТОЧНИК | То что пересобираем — главный вход | Волна 1: берём отсюда, переносим в новую структуру |
| Дополнительный материал | СПРАВОЧНИК | Где могут быть забытые данные | Волна 2: проверяем сюда, не переписываем |
Правило: СПРАВОЧНИК никогда не является источником правды. Он нужен только чтобы ничего не забыть.
Применяется когда происходит полная миграция платформы — структура меняется настолько, что простым переносом не обойтись.
ВОЛНА 1 — ПЕРЕНОС
Вход: ИСТОЧНИК (старая структура)
Процесс: пересобрать по актуальным стандартам → новая структура
Выход: новая структура (результат Волны 1)
Справочник: не трогаем
ВОЛНА 2 — ДОПРАВКА
Вход: результат Волны 1 + СПРАВОЧНИК
Процесс: пройти по справочникам → найти что забыли
сравнить с новой структурой → дополнить пропущенное
Выход: финальная структура без потерь
Алгоритм Волны 2:
1. Взять список всех файлов СПРАВОЧНИКА
2. Для каждого файла: есть ли его тема в новой структуре?
├── ДА → пропустить
└── НЕТ → показать оператору: "Этот контент не перенесён — нужен?"
3. Оператор решает: добавить / в prospective/ / архив
4. Обновить JOURNAL.md записью "Доправка из {справочник}: {что добавили}"
# В блоке ⚑ ЗОНЫ ПРОЕКТА
ИСТОЧНИК: путь/к/старой/структуре # откуда пересобираем (Волна 1)
СПРАВОЧНИК: путь/к/доп/материалам # где искать забытое (Волна 2)
РЕЗУЛЬТАТ: путь/к/новой/структуре # куда пишем
# Если справочников несколько — список:
СПРАВОЧНИК:
- architect/concept/ # старые концепции
- archive/2025-old/ # материалы прошлого года
После написания документа — до показа оператору — выполнить 18 проверок в 5 категориях. Исправить все несоответствия. Только после ✅ всех проверок → показать оператору.
При нарушении которое требует решения оператора → показать проблему, не документ.
| # | Проверка | Правило |
|---|---|---|
| А1 | Frontmatter — все обязательные поля (type, layer, object, aspect, form, title, status, version, date, knowledge_level, parent) | arch-document-format.md |
| А2 | Именование файла: [layer]-[object]-[aspect].(тип).md |
arch-naming-workspace.md |
| А3 | Поле form: соответствует содержимому (text/table/schema/code) |
arch-document-format.md |
| А4 | Размер < 500 строк | arch-document-system.md |
| А5 | Язык: документация = русский, переменные/ключи = английский | arch-platform-policy.md |
| # | Проверка | Правило |
|---|---|---|
| Б1 | parent: файл существует |
arch-document-linking.md |
| Б2 | Все файлы в deps: существуют |
arch-document-linking.md |
| Б3 | Все ссылки в тексте — относительные и ведут к существующим файлам | arch-document-linking.md |
| Б4 | supersedes: — старый файл существует и будет помечен |
arch-rebuild-operation.md |
| # | Проверка | Правило |
|---|---|---|
| В1 | К1/К2/К3 подтверждают что файл в правильном компоненте | arch-platform-structure.md §4.1 |
| В2 | knowledge_level: У0–У4 соответствует содержимому |
arch-document-system.md |
| В3 | Каскад соблюдён: theory→concept→standards→patterns | arch-document-system.md |
| В4 | Нет дублирующего документа на ту же тему | arch-rebuild-operation.md §4 |
| # | Проверка | Правило |
|---|---|---|
| Г1 | Нет credentials, токенов, паролей, IP-адресов | arch-security-policy.md С1 |
| Г2 | Нет конкретики платформы в абстрактном документе | arch-platform-structure.md §4.1 |
| Г3 | Нет изменений LOCKED файлов без явного разрешения | theory/ LOCKED |
| # | Проверка | Правило |
|---|---|---|
| Д1 | Все источники из SOURCES.md отражены в документе | arch-rebuild-operation.md §4 |
| Д2 | Терминология актуальная (не старые роли/названия) | arch-terminology.md |
| Д3 | status: соответствует полноте документа |
arch-document-format.md |
- [ ] doc.md deps: — А✅ Б✅ В✅ Г✅ Д✅
Команда /rebuild restart — сброс пересборки и повторный старт.
AI читает текущее состояние без вопросов к оператору. Обязательный порядок:
1. REBUILD.md §ЗОНЫ ПРОЕКТА — первым, без исключений
Блок ⚑ ЗОНЫ ПРОЕКТА содержит:
ПЕРЕСОБИРАЕМ — что является активной рабочей папкой
ДОП. ИНФО — откуда брать справку (только читать)
ФИНАЛ — куда переедет результат
ПОЗЖЕ — что не трогать сейчас
Без этого блока рестарт не начинается — AI запрашивает у оператора.
2. JOURNAL.md — последние 10 записей (если есть)
3. REBUILD.md остальные разделы — план и % выполнения
4. Реальная структура папок — что фактически создано
Правило зон: AI никогда не пишет в папки помеченные "только читать" или "не сейчас".
Если зоны не определены — остановиться и запросить у оператора таблицу зон перед любыми действиями.
Если служебных файлов нет — AI строит контекст из реальной структуры.
РЕСТАРТ: восстановлен контекст
Источники: {путь} — {N файлов}
Пространство: {путь} — {что там}
Доп. инфо: {путь} — {что там, если есть}
Прогресс: {N}% — {что сделано} / {что осталось}
Выберите режим:
1. ПОЛНЫЙ РЕСТАРТ
Архивировать служебные файлы (_archive/YYYY-MM-DD-reset/)
Создать новую рабочую папку (_rebuild-2/)
Начать SOURCES.md с нуля
2. КОРРЕКЦИЯ НА МЕСТЕ
Служебные файлы не трогать
Пройти по текущему состоянию
Внести только правки — не переписывать готовое
ПОЛНЫЙ РЕСТАРТ:
1. mv JOURNAL.md FACTS.md REBUILD.md SOURCES.md → _archive/YYYY-MM-DD-reset/
2. mkdir _rebuild-{N}/ (N = следующий номер)
3. Создать JOURNAL.md с пометкой "РЕСТАРТ от YYYY-MM-DD, причина: {оператор}"
4. Начать с ШАГ 0 → SOURCES.md
КОРРЕКЦИЯ НА МЕСТЕ:
1. Прочитать все служебные файлы
2. Составить список расхождений: план vs реальность
3. Показать оператору список коррекций
4. Применить только утверждённые правки
5. Обновить JOURNAL.md записью "КОРРЕКЦИЯ от YYYY-MM-DD"
При старте новой сессии читать служебные файлы проекта в таком порядке:
1. JOURNAL.md — где остановились, текущий цикл, следующий шаг
2. FACTS.md — подтверждённые факты (не переспрашивать оператора)
3. REBUILD.md — план, граф зависимостей, маппинг
4. прочие файлы истории — если есть
Правило: не задавать оператору вопросы, ответы на которые уже есть в этих файлах.
Сравнить реальное состояние объекта пересборки с целевой структурой:
| Объект | Статус | Что уже сделано | Что осталось |
|---|---|---|---|
| ... | % | перечень | перечень |
Показать оператору и получить подтверждение перед стартом.
В начале каждого проекта пересборки явно указать:
| Роль | Путь | Что там |
|---|---|---|
| ИСТОЧНИКИ | {откуда берём} |
файлы до пересборки |
| РЕЗУЛЬТАТЫ | {куда пишем} |
новые документы (WIP) |
| ФИНАЛ | {куда публикуем} |
утверждённый результат |
| ИСПОЛНЕНИЕ | {рабочая папка} |
_rebuild/ или sys-проект |
| ИСТОРИЯ | JOURNAL.md FACTS.md REBUILD.md |
лог, факты, план |
Эта таблица заполняется один раз в начале и остаётся неизменной.
Цель: любой AI открыв проект сразу понимает — откуда берём, куда кладём, где результат.
Правило: не начинать SOURCES.md пока аудит не показал полную картину.
Перед запуском пересборки — изучить что уже сделано.
Источники аудита:
- Системный проект платформы (projects/sys/platform-update/)
- Стандарты в разработке (standards/)
- Уже пересобранные компоненты (файлы с status: active, status: approved)
- Предыдущие REBUILD.md и JOURNAL.md
Вопросы аудита:
| Вопрос | Где смотреть |
|---|---|
| Какие стандарты уже приняты? | standards/arch-*.md → status: |
| Какие компоненты уже пересобраны? | REBUILD.md предыдущих сессий |
| Что ещё не тронуто? | Сравнить с целевой структурой |
| Есть ли конфликты между старым и новым? | Сравнить старые docs с новыми стандартами |
Результат аудита — таблица состояния:
| Компонент | Статус | Что сделано | Что осталось |
|-----------|--------|-------------|-------------|
| architect/ | 🔄 частично | standards/ пересобраны | rules/ отсутствует, лишние папки |
| projector/ | ❌ не начато | — | создать с нуля |
| library/ | ⚠️ требует решения | — | Python-код не там |
Правило: не начинать SOURCES.md пока аудит не показал полную картину.
Масштаб пересборки определяет где ведётся работа:
| Масштаб | Формат | Где |
|---|---|---|
| 1 папка / компонент | _rebuild/ внутри папки |
рядом с файлами |
| 2+ папки | системный проект | project/sys/{имя}/ |
| Вся сложная система | системный проект + рекурсия | project/sys/{имя}/ |
Малая пересборка (1 папка):
{папка}/
├── _rebuild/ ← рабочая папка новой версии
│ ├── SOURCES.md
│ ├── FACTS.md
│ ├── REBUILD.md
│ ├── JOURNAL.md
│ └── ... новые документы
├── _archive/
│ └── YYYY-MM-DD/ ← текущие файлы уходят сюда
└── ... текущие файлы (остаются пока идёт работа)
Сложная система (много папок) — дополнительная фаза -1:
project/sys/{имя}/
├── ARCHITECTURE.md ← новая структура верхнего уровня (фаза -1)
├── SOURCES.md
├── FACTS.md
├── REBUILD.md ← список папок + порядок рекурсии
└── JOURNAL.md
Порядок рекурсии — строго по зависимостям:
arch/ → project/ → domains/ → system/ → services/ → infra/
Папка X не начинает пересборку пока все её зависимости не завершены ✅
Каждая пересборка ведётся через четыре файла. Порядок заполнения строгий:
1. SOURCES.md — RAG: индекс всего что есть внутри и снаружи папки
2. FACTS.md — правда: подтверждённые факты + решения оператора
3. REBUILD.md — план: новая структура, граф зависимостей, маппинг
4. JOURNAL.md — лог: решения и действия по ходу работы
Почему именно такой порядок:
- Нельзя планировать не зная что есть → SOURCES первый
- Нельзя спрашивать оператора не зная конфликтов → FACTS после SOURCES
- REBUILD — итог SOURCES + FACTS, не раньше
- JOURNAL — пустой в начале, заполняется по ходу
Четыре источника правды (по убыванию приоритета):
P1 FACTS.md — подтверждённые слова оператора
P2 Новые документы — уже написанные в _rebuild/
P3 Старые документы — из пересобираемой папки
P4 Анализ по теме — из других мест платформы
Правило последней правды: последнее утверждение оператора по теме сильнее предыдущего. При конфликте — показать оба с датой, оператор выбирает.
Два раздела: файлы → темы, темы → файлы.
# SOURCES
## 1. Файлы → темы
### Внутри папки
| Файл | Строк | Темы | Ссылается на | На него ссылаются |
|------|-------|------|-------------|------------------|
| doc1.md | 320 | frontmatter, структура | doc2.md | doc3.md |
### Снаружи (связанные)
| Файл | Строк | Темы | Ссылается на | На него ссылаются |
|------|-------|------|-------------|------------------|
| ../concept/metamodel.md | 116 | У0-У4, каскад | — | doc1.md |
## 2. Карта тем → файлы
ТЕМА ВЕРХНЕГО УРОВНЯ
1.1 Подтема [источник1.md, источник2.md]
1.2 Подтема [источник3.md]
1.2.1 Деталь [источник1.md]
Два прохода при заполнении:
1. Внутри папки — все файлы, темы, ссылки
2. Снаружи — файлы на которые ссылаются изнутри + файлы которые ссылаются внутрь
Карта тем — основа для предложения новой структуры файлов оператору.
Подтверждённые факты от оператора. Только то что явно утверждено — не выводы AI.
# FACTS
## Подтверждённые факты
| Факт | Источник | Дата |
|------|---------|------|
| Формула именования: [layer]-[object]-[aspect].(тип).md | чат 2026-04-10 | 2026-04-10 |
| FORM — поле frontmatter, не часть имени | чат 2026-04-11 | 2026-04-11 |
## Открытые вопросы
| Вопрос | Варианты | Статус |
|--------|---------|--------|
| Нужен ли INDEX.md в модулях? | да / нет | ⏳ |
Порядок показа оператору:
1. Конфликтные факты — по одному
Показываем конфликт → оператор выбирает → следующий конфликт
2. Остальные факты — одним списком
Показываем все неконфликтные → оператор говорит "да"
FACTS.md закрыт только после явного "да" оператора на весь список.
Правило потерь: ничего не выбрасывается без подтверждения. Выброшенное фиксируется в _rebuild/_discarded.md.
# REBUILD — {название}
Дата: YYYY-MM-DD
## Новая структура файлов
| Файл | Папка | Что содержит | Строк (план) |
|------|-------|-------------|-------------|
## Порядок генерации (граф зависимостей)
- [ ] doc-A.md deps: —
- [ ] doc-B.md deps: doc-A.md
- [ ] doc-C.md deps: doc-A.md, doc-B.md
## Порядок хранения
{куда ложится каждый файл после финализации}
## Маппинг старые → новые (без потерь)
| Старый файл / тема | → Новый файл | Раздел |
|--------------------|-------------|--------|
## Матрица проверок (перед финализацией)
- [ ] Полнота тем — каждая тема из SOURCES → есть в новом документе
- [ ] Без потерь — каждый старый файл замаплен
- [ ] Размер — каждый файл в зелёной зоне (< 500 строк)
- [ ] Каскад — У0→У1→У2 без противоречий
- [ ] Ссылки — все относительные, ведут к существующим файлам
- [ ] Именование — все файлы по формуле [layer]-[object]-[aspect].(тип).md
- [ ] Дубли — одна тема = один файл
- [ ] Зависимости — порядок генерации соблюдён
- [ ] Связывание — Цикл 2 выполнен: parent:/deps: проставлены, индексы родителей обновлены
- [ ] Стабильность — Цикл 3 не породил новых изменений
Все 10 проверок ✅ → только тогда переносим из _rebuild/ в корень.
# JOURNAL
## [YYYY-MM-DD HH:MM] Сессия открыта
Позиция: doc-B.md §3 (продолжаем с §3)
## [YYYY-MM-DD HH:MM] Действие
Тип: создан / перемещён / слит / удалён / обсуждён
Файл: path/to/file
Откуда: source.md §2 + source2.md §4
Зачем: краткое обоснование
## [YYYY-MM-DD HH:MM] Решение
Тема: ...
Выбрано: ...
Альтернативы: ...
## [YYYY-MM-DD HH:MM] Сессия закрыта
Позиция: doc-C.md — не начат
Следующий шаг: начать doc-C.md, deps: doc-B.md ✅
Правило: при открытии сессии AI читает последние 10 записей → знает где остановились → продолжает без вопросов.
ПЕРЕСБОРКА выполняется в несколько циклов. Причина: создание новых документов порождает новые зависимости — верхние документы ссылаются на нижние, нижние регистрируются в верхних. После первого прохода граф зависимостей меняется.
Три цикла:
Цикл 1 — ГЕНЕРАЦИЯ
Написать документы по графу зависимостей из REBUILD.md.
По ходу: появляются новые документы, обсуждения меняют структуру.
Результат: все документы написаны, матрица проверок ✅
Цикл 2 — ПЕРЕСБОРКА ЗАВИСИМОСТЕЙ
Запустить операцию СВЯЗЫВАНИЕ по всем новым документам:
- проставить parent: и deps: в frontmatter каждого файла
- зарегистрировать каждый документ в индексе родителя
- проверить что все ссылки ведут к существующим файлам
Результат: граф зависимостей актуален, ссылки живые
Цикл 3 — ПРОХОД ПО ЗАВИСИМЫМ
Пройти повторно по документам которые ссылаются на новые:
- верхние документы (parent) — обновить раздел ссылок
- нижние документы (deps) — проверить что контент соответствует новым стандартам
Результат: вся цепочка согласована сверху вниз
Правило остановки: если в Цикле 3 изменений нет — пересборка завершена. Если появились изменения → повторить Цикл 2 и Цикл 3.
Цикл 4 — АНАЛИЗ РАЗРЫВОВ (запускается после Цикла 3)
1. Собрать все случаи где оператор за время пересборки:
- не согласился с предложенным вариантом
- дописал то чего AI не предложил
- исправил направление
- добавил компонент/документ которого не было в плане
2. По каждому случаю ответить:
ПОЧЕМУ AI не пришёл к этому сам?
→ не хватало контекста?
→ нет стандарта на эту тему?
→ нет паттерна?
→ нет компонента?
→ неверная модель предметной области?
3. Предложить конкретное изменение которое закрыло бы разрыв:
→ новый стандарт / дополнение к существующему
→ новый паттерн
→ новый компонент
→ уточнение концепции
Результат: GAP_REPORT.md
| Разрыв | Почему AI не нашёл | Предложение | Приоритет |
|--------|------------------|------------|----------|
GAP_REPORT.md → передать в system/monitor/reports/arch/
В JOURNAL.md фиксировать: текущий цикл и позицию внутри него.
## [YYYY-MM-DD] Цикл 2 — ПЕРЕСБОРКА ЗАВИСИМОСТЕЙ
Обработано: arch-document-format.md, arch-document-system.md
Осталось: arch-workspace-structure.md, arch-project-structure.md
Финализация — только после того как все 8 проверок в REBUILD.md отмечены ✅ и Цикл 3 не породил новых изменений.
Три шага:
1. Текущие файлы → _archive/YYYY-MM-DD/
2. Файлы из _rebuild/ → корень папки
3. Папка _rebuild/ удаляется
Откат (если что-то пошло не так):
# Всё текущее удалить
# Вернуть из _archive/YYYY-MM-DD/
Поэтому _archive/ не трогаем до тех пор пока новая версия не проверена в работе.
Правило: финализация — отдельная сессия. Не совмещать с генерацией документов.