Приложение В: Zulip АйТек — сущностная модель и жизненный цикл проекта (заказа)

Приложение В к РГ-СМК-Zulip-01.
Дополнение к карте каналов. Здесь — скелет, на котором держится вся логика: знание о контрагентах и объектах, и проходящий через стадии проект (= заказ).
Терминология (важно)
Слово
Значение в АйТек
Где
Проект
заказ клиента — поставка НКУ/РУСН на конкретный объект, со своим жизненным циклом
сквозной объект потока, канал 
#проекты, тема 
Проект: …
Развитие
внутренние инициативы и изменения: цифровизация, интеграция, изменения СМК
канал 
#развитие (
Инициатива:), владелец — LeanTech + СМК
«Проект» закрепляем за заказом (язык бизнеса). Внутренние инициативы переименовываем в 
#развитие, чтобы одно слово не означало две разные вещи.
Сущностный спайн
Логика навешана не на стадии потока, а на сущности и их связи:
Контрагент ──1:N──► Объект ──1:N──► Проект (=заказ) ──1:N──► Изделия
 заказчик,          площадка/        конкретная               НКУ 0,4 кВ,
 генподрядчик,      сооружение       поставка на объект        РУСН-10,
 поставщик,         (ПС, завод,      со своим ЖЦ              подстанции
 субподряд          ЖК, цех)         (G0…G8)
Это граф, а не строгое дерево: у одного объекта может быть несколько контрагентов (заказчик, генподряд, проектировщик), а проект тянет ещё и поставщиков. Поэтому модель живёт как связанные записи, а не как вложенные папки.
Где что живёт (четыре слоя):
CRM/ERP — источник истины по сущностям: карточки Контрагентов, Объектов, Проектов и связи между ними (граф сущностей).
KB (BookStack) — источник истины по документам: регламенты, стандарты КД, методики; коммерческий раздел держит профили контрагентов и объектов как знание.
Zulip — обсуждение, навешанное на сущности через карточку темы и нейминг. Чат не хранит сущности, он на них ссылается.
Onyx — индексирует все три источника; сущности становятся якорями retrieval, поэтому «знание об объекте/контрагенте» отвечается поверх записей, документов и обсуждения.
Тема проекта в Zulip
Чтобы тема несла объект и контрагента (а не только номер), первое сообщение темы = карточка проекта со ссылками в структурный слой.
Имя темы (коротко, стабильно): 
Проект: <код объекта> / <№> Пример: 
Проект: ПС-Северная / 2026-312
Карточка (первое сообщение):
Контрагент:  ООО «Ромашка» (заказчик) · ГК «Стройсервис» (генподряд)
Объект:      ПС 110/10 кВ «Северная», г. Подольск
Проект №:    2026-312    ·    Договор: №10/02
Состав:      НКУ 0,4 кВ — 12 шкафов · РУСН-10 — 3 ячейки
Срок:        отгрузка до 2026-09-15
Записи:      CRM/ERP ↔ <ссылка>   ·   KB ↔ <ссылка>
Статус:      G2 — договор подписан, в проектировании
Эта карточка даёт и людям, и Onyx три якоря сразу — контрагент, объект, проект — по любому из которых ищется контекст.
Жизненный цикл проекта (шлюзы)
Тема 
Проект: — сквозная, идёт через стадийные каналы. На каждом шлюзе статус обновляется в карточке; стандартная работа стадии остаётся в стадийном канале.
Проект: <Объект> / <№>
   │
 G0  лид / запрос на объект            #продажи     → квалификация
   ▼
 G1  расчёт себестоимости + КП         #продажи     → отправлено клиенту
   ▼
 G2  договор подписан                  #продажи     → проект «в работу»
   ▼
 G3  КД готова                         #проектирование → запуск в производство
   ▼
 G4  материалы обеспечены              #снабжение
   ▼
 G5  изделие собрано                   #производство  (Подольск / Кострома)
   ▼
 G6  ОТК / ПСИ пройдены ▣шлюз          #качество     → готово к отгрузке
   ▼
 G7  отгружено на объект               #отгрузка
   ▼
 G8  ПНР / сдача                       #сервис       → проект закрыт
Стадийный канал ведёт повторяющуюся работу стадии (мощности, нормы, типовые проблемы), а конкретный проект — сквозную тему; из стадии на проект ссылаемся через 
#проекты>Проект: …. Решение по проекту фиксируем 
Решение: внутри его темы; рекламацию — 
Рекламация: в 
#качество со ссылкой на объект и проект.
Что это открывает (запросы к Onyx)
Сущности-якоря превращают разрозненную переписку в навигируемое знание:
По контрагенту: «все проекты ООО Ромашка», «история рекламаций по этому заказчику».
По объекту: «что у нас по ПС Северная за всё время», «какие изделия туда уходили».
По проекту: «статус 2026-312», «что решили по составу щитов».
Срез по шлюзу: «какие проекты застряли на G4 (снабжение)».
Без сущностного спайна эти запросы недоступны — есть только тысячи сообщений. Со спайном — это и есть «знание об объектах и контрагентах», ради которого всё строится.
Связь с базой знаний (KB)
Контрагент / Объект / Проект — это коммерческий раздел KB в действии: именно эти сущности делают базу знаний навигируемой, а не складом документов. Один словарь сущностей между CRM/ERP, KB и Zulip-темами — обязательное условие, чтобы Onyx видел единый граф, а не три разных языка для одного объекта.
Нейминг един во всём комплекте: 
Проект: = заказ (
#проекты), 
Инициатива: = изменение (
#развитие). Это приложение В; грамматика тем — приложение А (
itech-zulip-ontology.md), карта потока — приложение Б (
itech-zulip-channels-valuestream.md); ядро — регламент РГ-СМК-Zulip-01 (
itech-zulip-reglament-start.md).