type: standard
aspect: process
title: "Процесс изменений платформы"
version: 0.1.0
date: 2026-03-30
status: draft

Процесс изменений платформы

ЧЕРНОВИК — не применять до финализации

СУТЬ

Любое изменение платформы проходит единый путь:

IDEA → DRAFT → REVIEW → PLAN → MIGRATION → RELEASE

Ничто не появляется в платформе минуя этот путь.

СТАДИИ

IDEA — сырая идея

Когда: появилась мысль, ещё не оформлена.

Артефакт: name.idea.md — в папке где будет жить документ.

Содержимое: свободный текст, гипотеза, наброски.

Переход в DRAFT: когда идея достаточно оформлена чтобы обсуждать конкретику.

DRAFT — черновик

Когда: идея оформлена, начинается проработка.

Артефакт: name.draft.md

Обязательные секции:

## СУТЬ
Что меняем и зачем.

## ИЗМЕНЕНИЯ
Конкретный список что добавляется / изменяется / удаляется.

## АНАЛИЗ СООТВЕТСТВИЯ
Проверка на соответствие стандартам платформы.
Конфликты с существующими правилами.

## ОТКРЫТЫЕ ВОПРОСЫ
Что не решено, требует обсуждения.

Переход в REVIEW: когда черновик готов к обсуждению.

REVIEW — анализ и обсуждение

Что происходит:
- Проверка на соответствие стандартам (naming, structure, policy)
- Обсуждение открытых вопросов
- Правки вносятся прямо в .draft файл
- Фиксация решений в секции ## РЕШЕНИЯ

Артефакт: тот же .draft файл, дополненный секцией:

## РЕШЕНИЯ
- [вопрос] → [решение] ([дата])

Переход в PLAN: когда все вопросы закрыты.

PLAN — план миграции

Что происходит: в черновике создаётся конкретный план — что где менять.

Добавляется секция:

## ПЛАН МИГРАЦИИ

### Файлы
- [ ] переименовать X → Y
- [ ] создать Z
- [ ] архивировать W → arh/

### Компоненты
- [ ] переименовать @admin.portal → @admin.ui

### Документы
- [ ] обновить ссылки в INDEX.md
- [ ] обновить architect/CLAUDE.md

### Реестр
- [ ] добавить в INDEX.md
- [ ] обновить README.md раздела

Переход в MIGRATION: план утверждён.

MIGRATION — выполнение изменений

Что происходит: выполняются все пункты плана по чеклисту.

Правила:
- Каждый пункт отмечается [x] после выполнения
- Все изменения в одном коммите (или серии связанных коммитов)
- Коммит-сообщение ссылается на черновик

Переход в RELEASE: все пункты плана отмечены [x].

RELEASE — публикация

Что происходит:

1. Черновик становится активным документом:
   git mv name.draft.md name.md

2. Если был старый активный документ — в архив:
   git mv name.md arh/name-YYYY-MM-DD.md git mv name.draft.md name.md

3. Обновляется реестр (INDEX.md, README.md раздела).

4. .idea.md если был — удаляется (поглощён черновиком).

ПРАВИЛА

1. Любое изменение платформы начинается с .draft или .idea
2. Нет прямых изменений — нельзя сразу редактировать активный документ
3. План до действий — миграция начинается только после утверждения плана
4. Реестр как часть миграции — обновление реестра входит в план, не делается отдельно
5. Один черновик — одно изменение — не смешивать несвязанные изменения

ОТКРЫТЫЕ ВОПРОСЫ

• [ ] Нужен ли формальный "реестр" черновиков? Или достаточно find . -name "*.draft.md"?
• [ ] Кто утверждает переход PLAN → MIGRATION? (Архитектор? Автоматически?)
• [ ] Как версионировать документы если изменений несколько в год?
• [ ] Связь с .queue/ — задача на миграцию создаётся как .task.yaml?

СВЯЗЬ С DMS

Этот процесс — часть большой системы управления документами (DMS).

→ DMS описывает полный жизненный цикл: от идеи до архива, реестры, поиск, актуализация.

→ [DMS проект] — отдельный проект платформы (создать).

РЕФОРМА — особый тип изменения

Когда использовать реформу (а не обычный .draft):
- Изменение затрагивает 3+ файлов
- Файлы логически связаны (одна область: именование, структура, процесс)
- Нужно обсудить изменения как единое целое до применения

Структура реформенного документа:

## 1. МАНИФЕСТ
- Цель и обоснование
- Архивируем: список файлов → arh/
- Создаём: новые файлы
- Обновляем: изменения в существующих
- Не трогаем

## 2. АНАЛИЗ И ТОМОГРАФИЯ
- Проблемы текущего состояния
- Соответствие концепции платформы
- Томография финального результата (5 измерений)

## 3. ЧЕКЛИСТ МИГРАЦИИ
[ ] пункты

## 4. ДОКУМЕНТ 1: name.md
[полный контент нового файла]

## N. ПОПРАВКИ В ДРУГИЕ ДОКУМЕНТЫ
[правки к файлам вне области реформы — применяются после]

Именование: reform-{area}.draft.md

reform-naming-arch.draft.md
reform-agent-system.draft.md

После применения: реформенный документ → arh/reform-{area}-YYYY-MM-DD.md

Правило: один реформенный документ — одна связанная область. Не смешивать несвязанные реформы.

Версия: 0.2.0 (черновик)
Дата: 2026-03-31