# MHS ERP Construction — руководство по реализации

## 1. Что передано

Пакет является самодостаточным снимком текущего продукта:

- кликабельный локальный интерфейс;
- локальное серверное ядро на Node.js и SQLite;
- каноническая модель объекта, полного результата генподряда, 40 работ и инженерных систем, 43 ролевых контрактов и 175 точных передач;
- исходная предметная модель;
- автоматические проверки ключевых границ;
- отдельный портал проверки техническим директором;
- полная книга продукта в Markdown, Word и PDF.
- актуальный пакет владельца, технического директора и профильных специалистов с исходными хэшами.

Старые архивы, резервные копии, исторические варианты интерфейса и прежние отчёты в пакет не включены.

## 2. Текущий уровень готовности

Статус: **LIMITED**.

Реализовано и проверяется локально:

1. паспорт эталонного многоквартирного жилого комплекса с отдельным коммерческим классом и явно отмеченными неопределёнными параметрами;
2. полный договорный результат генерального подрядчика, разделительная матрица и каталог работ и инженерных систем;
3. 11 внутренних кабинетов генподрядчика, 3 внешних интерфейса и 1 сквозной контур передачи;
4. единая машинная модель ролей, передач, записей, контрольных точек и решений;
5. постоянное локальное состояние SQLite;
6. адресные действия по документным подачам и передачам;
7. защита от повторного запроса на уровне локального ядра;
8. цепочка аудита локальных критичных действий;
9. автоматические тесты структуры и сценариев.

Не реализовано как промышленная система:

1. многопользовательский сервер и база промышленного класса;
2. файловое хранилище с версиями и проверенным восстановлением;
3. корпоративная идентификация, многофакторная защита и полная матрица прав;
4. очереди, повторы, карантин и наблюдаемость интеграций;
5. юридически значимая электронная подпись;
6. реальные подключения почты, редакторов, календарного графика, чертежей, склада, финансов, геодезии и лаборатории;
7. отдельные среды разработки, проверки и эксплуатации;
8. нагрузочные испытания, информационная безопасность и эксплуатационный регламент.

## 3. Непереговорная продуктовая архитектура

1. Исходная точка — паспорт объекта, договорный результат генподряда и состав работ, а не перечень ролей.
2. Верхний уровень разделён на 11 внутренних кабинетов генподрядчика, 3 интерфейса самостоятельных внешних участников и 1 сквозной контур передачи.
3. 43 ролевых контрактов являются профилями и назначениями внутри соответствующих организаций и рабочих пространств.
4. Один сотрудник может иметь несколько назначений, но совмещение не отменяет независимую проверку.
5. Каждая работа или инженерная система имеет полное наименование, направление, зону, действующие основания, результат, доказательства, приёмку и пусконаладку.
6. Передача всегда содержит отправителя, точный пакет, условие, получателя, его действие и возврат.
7. Документы и переписка ссылаются на одну каноническую запись, а не создают копии истины.
8. Агент работает только в ограниченном контексте задачи и не принимает юридически или производственно значимые решения.
9. Нормативный источник, исследование, дизайн-референс и технический кандидат не являются пользовательской функцией без доказанной потребности.

## 4. Структура переданной исходной папки

```text
03_PRODUCT_SOURCE_AND_RUNTIME/
├── product/                 # пользовательский интерфейс
├── prepilot-core/           # локальное серверное ядро и SQLite
├── source/                  # каноническая предметная модель
├── research/                # изолированные исследовательские кандидаты
├── brand/                   # правила интерфейса и токены
├── tests/                   # автономные проверки переданного снимка
├── role-model.json          # полный машинный снимок
├── START_MHS_ERP.command    # запуск на macOS
├── START_MHS_ERP.bat        # запуск на Windows
└── package.json             # команды запуска и проверки
```

## 5. Локальный запуск

Требование: Node.js 24.14 или новее.

### macOS

Открыть `START_MHS_ERP.command`.

### Windows

Открыть `START_MHS_ERP.bat`.

### Командная строка

```bash
npm start
```

Продукт откроется на `127.0.0.1`. Порт выбирается автоматически в macOS-скрипте. Локальная база создаётся внутри папки продукта в `.runtime/`.

## 6. Проверка перед изменениями

```bash
npm test
```

Проверки должны подтвердить:

- 11 внутренних кабинетов генподрядчика, 3 внешних интерфейса и 1 сквозной контур;
- 40 работ и инженерных систем;
- 43 роли;
- 175 передач;
- отсутствие ролевых клонов;
- разделённую организационную, а не ролевую верхнюю навигацию;
- отсутствие технических кандидатов в пользовательских функциях;
- отделение внутренней архитектуры и симуляций от рабочего интерфейса;
- работа локального серверного ядра и сценариев возврата.

## 7. Целевая промышленная схема

### Пользовательский слой

- веб-интерфейс кабинетов;
- мобильные сценарии участка;
- просмотр документов, чертежей и моделей;
- очереди, карточки результатов, передачи, возвраты и блокировки;
- доступность и адаптивность.

### Прикладной сервер

- единые команды и правила состояния;
- маршрутизация по назначениям;
- проверка независимости автора и принимающего;
- комплектность и версии;
- идемпотентность;
- аудит до/после;
- интеграционные адаптеры;
- агентская подготовка черновиков.

### Данные

- реляционная база для объектов, назначений, работ, документов, состояний и решений;
- объектное файловое хранилище для версий и доказательств;
- очередь фоновых задач;
- индекс поиска с фильтрацией по правам;
- неизменяемый журнал;
- резервная копия и регулярно доказуемое восстановление.

### Идентификация и права

- организация → объект → кабинет → назначение → направление → зона → действие;
- многофакторная защита;
- временное замещение;
- запрет самопроверки;
- отрицательные тесты прав;
- отдельная проверка полномочий подписанта.

## 8. Последовательность реализации

### Этап 1. Серверное основание

1. схема данных;
2. файловое хранение;
3. идентификация и назначения;
4. права и запрет самопроверки;
5. канонические записи и версии;
6. очереди, возвраты и блокировки;
7. неизменяемый журнал;
8. резервное копирование и доказуемое восстановление.

Критерий выхода: один объект можно восстановить вместе с файлами, версиями, правами и аудиторской цепочкой.

### Этап 2. Документный и производственный маршрут

1. объектная матрица форм;
2. комплектность;
3. подача, замечание, возврат и повторная подача;
4. контрольные точки;
5. запрет следующей операции;
6. принятый объём и основание КС.

Критерий выхода: один сквозной пакет проходит от фронта работ до принятого результата без ручного дублирования.

### Этап 3. Минимальные подключения

1. корпоративная почта;
2. офисные документы и таблицы;
3. календарно-сетевой график;
4. DWG/DXF и IFC/BCF;
5. закупки и склад;
6. финансы;
7. геодезия и лаборатория.

Каждое подключение принимается только после проверки повторов, ошибок связи, дублей, сверки и обратной загрузки.

### Этап 4. Подпись и промышленная эксплуатация

1. электронная подпись;
2. раздельные среды;
3. мониторинг;
4. нагрузка и безопасность;
5. эксплуатационный регламент;
6. персональные данные и размещение информации;
7. очная приёмка ролей.

### Этап 5. Агентское сопровождение

Агент получает только разрешённый контекст записи, показывает источники и версии, готовит черновик и следующий пакет, выявляет дефицит. Подпись, приёмка, объём, платёж и снятие стопа остаются действиями человека.

## 9. Обязательные входы от пилота

1. один реальный обезличенный объект;
2. организационная структура и назначения;
3. матрица документов, проверяющих и подписантов;
4. перечень действующих программ и владельцев подключений;
5. действующие специалисты для приёмки кабинетов;
6. решение Q-007 по показателям каждой роли.

## 10. Правило изменения модели

Изменение сначала фиксируется кодом сущности и доказательством. Затем обновляется канонический источник, машинная модель, интерфейс, книга, тест и журнал решения. Нельзя добавлять функцию только потому, что она встретилась в исследовании или открытом репозитории.