# Приложение А: Zulip АйТек — грамматика тем и индексация Onyx *Приложение А к РГ-СМК-Zulip-01.* Детализация к регламенту: правила именования тем и индексации Onyx. Две оси: **канал** = кто участвует и кто это видит (стабильная ось, граница доступа и индексации Onyx); **тема** = о чём конкретно (единица знания, то, что Onyx достаёт и цитирует). Канонические описания каналов, словарь и стартовый контур — в регламенте. --- ## Схема ``` ОСЬ КАНАЛОВ (кто · доступ · индексация Onyx) ───────────────► ┌────────────────┬────────────────┬────────────────┐ │ #продажи │ #развитие │ #качество │ │ функция │ изменения │ функция │ │ операционка │ (инициативы) │ ISO 9001 │ ├────────────────┼────────────────┼────────────────┤ │ Клиент: │ Инициатива: │ Регламент: │ │ Сделка: │ …ERP │ Аудит: │ │ Проблемный │ …Zulip │ Несоответствие:│ │ кейс │ …GRACE │ CAPA: │ │ │ │ Анализ рук-ва: │ └────────────────┴────────────────┴────────────────┘ ОСЬ ТЕМ (о чём · единица знания) ▼ Сквозной канал #проекты (заказы): тема = Проект: <объект>/<№> Сквозные типы (в любом канале): Решение: Рекламация: ``` Канал — медленная ось: каналов мало, они почти не меняются. Тема — быстрая: их много, они динамичны. Вся дисциплина сводится к тому, чтобы не путать две оси и держать закрытый список префиксов тем. --- ## Описания каналов (для `description` в Zulip) Грамматико-ориентированная версия; канонические формулировки — в регламенте, п. 3. ### `#продажи` > Операционная работа отдела продаж: лиды, клиенты, сделки, проблемные кейсы. Изменения процессов и инициативы — НЕ сюда, а в `#развитие`. Вопросы качества и претензии клиентов — в `#качество`. Темы: `Клиент:`, `Сделка:`, `Проблемный кейс`. ### `#развитие` > Внутренние инициативы и изменения: цифровизация, интеграция систем, изменения СМК. Одна тема = одна инициатива (`Инициатива: …`). Итог фиксируем темой `Решение: …`. Текущие: `Инициатива: Внедрение ERP`, `Инициатива: Внедрение Zulip`, `Инициатива: Интеграция GRACE`. Темы: `Инициатива:`. ### `#качество` > Контроль (ОТК, лаборатория) и система менеджмента качества (ISO 9001): регламенты, аудиты, несоответствия и корректирующие действия, рекламации, анализ со стороны руководства. Изменение/пересмотр регламента как инициатива — в `#развитие`, сюда возвращаем ссылкой. Темы: `Регламент:`, `Аудит:`, `Несоответствие:`, `CAPA:`, `Рекламация:`, `Анализ рук-ва:`. ### `#проекты` (сквозной — заказы) > Сквозные заказы: одна тема = один проект `Проект: <объект> / <№>`, первое сообщение — карточка, статус по шлюзам G0–G8. Детально — приложение В (сущностная модель). --- ## Грамматика тем (закрытый список) Префикс + стабильное имя. Префиксы — закрытый список, синонимы не плодим (`Заявка:`/`Лид:`/`Обращение:` → выбрано одно). Именно `префикс + имя` становится меткой документа в Onyx. | Префикс | Канал | Что обозначает | Пример имени | | --- | --- | --- | --- | | `Проект:` | `#проекты` | заказ (сквозная тема) | `Проект: ПС-Северная / 2026-312` | | `Инициатива:` | `#развитие` | внутренняя инициатива / изменение | `Инициатива: Внедрение ERP` | | `Клиент:` | `#продажи` | контекст по клиенту | `Клиент: ООО Ромашка` | | `Сделка:` | `#продажи` | конкретная сделка / пайплайн | `Сделка: ВРУ для Ромашки` | | `Проблемный кейс` | `#продажи` | проблемная операционная ситуация | `Проблемный кейс: срыв отгрузки` | | `Регламент:` | `#качество` | обсуждение регламента (канон — страница KB) | `Регламент: Входной контроль` | | `Аудит:` | `#качество` | внутренний или внешний аудит | `Аудит: Внутренний, Q2-2026` | | `Несоответствие:` | `#качество` | зафиксированное несоответствие | `Несоответствие: партия №312` | | `CAPA:` | `#качество` | корректирующее / предупреждающее действие | `CAPA: по несоответствию №312` | | `Анализ рук-ва:` | `#качество` | анализ со стороны руководства | `Анализ рук-ва: 2026 H1` | | `Решение:` | любой | зафиксированное решение + обоснование | `Решение: выбор корп. мессенджера` | | `Рекламация:` | `#качество` (ссылка из `#продажи`) | претензия клиента + разбор | `Рекламация: Ромашка, дефект сборки` | --- ## Правила **Канон vs обсуждение.** Документ — источник истины (регламент, стандарт КД, методика) живёт страницей в KB (BookStack). В Zulip под `Регламент:` идёт его обсуждение и изменение, со ссылкой на страницу KB. `Решение:`, ставшее нормой, повышается до страницы KB. Не держим канонические документы «вечными» темами в чате — иначе истина расползается между чатом и базой. **Изменение vs эксплуатация — куда писать «изменение СМК».** *Изменение* с началом, концом и проектным управлением → `#развитие` (`Инициатива: Пересмотр регламентов под новую редакцию ISO`). *Установившийся артефакт и его эксплуатация* (сам регламент в KB, его аудит, несоответствия по нему) → `#качество`. СМК ведёт steady-state в своём канале, а изменение заводит инициативой в `#развитие` и оттуда ссылается назад. **`Решение:` — институциональная память.** Как только тред дошёл до решения, заводим (или переименовываем тему в) `Решение: …` с самим решением и кратким обоснованием. Это самый ценный для Onyx тип: на запрос «что мы решили по X» движок отдаёт чистую цитату, а не разбирает переписку. **`Рекламация:` — один источник истины на инцидент.** Факт услышан в `#продажи`, но авторитетная запись и корректирующее действие — в `#качество` (`Рекламация: …` + связанная `CAPA: …`). Из `#продажи` ставим ссылку через `#качество>тему`. Не дублируем обсуждение в двух каналах — иначе в индексе окажется три полуверсии одного инцидента. **Стабильность тем.** Тему не переиспользуют под новый предмет — заводят новую. Один «документ» не должен противоречить сам себе во времени. **Один словарь.** Типы тем и сущности должны совпадать с лексикой словаря и разделов KB, чтобы Onyx, индексируя все источники, видел согласованную онтологию, а не несколько языков для одних сущностей. --- ## Связь с Onyx * **Канал/полка = граница индексации и доступа.** Коннектор (Zulip, BookStack) забирает то, что видит его токен. Подписка/доступ = осознанное решение «идёт в RAG: да/нет». * **Источники и приоритет.** KB (BookStack) — канон, отличные RAG-документы (полка/книга/глава = готовая метадата, версии). Zulip — обсуждение и свежий статус. В ассистентах приоритет KB для «что является истиной», Zulip — для «что нового». * **Тема/страница = единица retrieval.** Префикс + стабильное имя работают как заголовок документа и метка цитаты; по ним строятся ассистенты (например, только по `Решение:`-темам или по document set раздела СМК в KB). * **Чувствительное защищаем не правами Zulip, а тем, что коннектор не подписан** — либо отдельным document set с ограниченным доступом. Пер-юзерные права источников в Onyx автоматически не переносятся. --- ## Масштабирование (разделы KB) Текущие области — проекция будущей карты разделов базы знаний; при расширении ничего не переделывается. | Сейчас | Раздел KB | Потом | | --- | --- | --- | | `#продажи` | Коммерческий | + `#снабжение`, `#финансы` и т.д. | | `#качество` | СМК / ISO 9001 | — | | `#развитие` | *ортогонален* | слой изменений для всех разделов | | — | Инженерный | `#проектирование` | | — | Производственный | `#производство` | --- ## Чек-лист **При создании канала:** * Решить: индексирует ли его Onyx-бот (да/нет), записать в `description`. * Чувствительное (цены, переговоры, претензии с юр. риском) → бот не подписан или отдельный document set. * В `description` указать «что сюда / что не сюда» и список префиксов тем. **При создании темы:** * Префикс — из закрытого списка выше. * Имя стабильное; новый предмет → новая тема. * Дошли до решения в треде → завести/переименовать в `Решение: …`; норма → страница KB. * Рекламация → запись в `#качество`, ссылка из `#продажи`.