Навигация: База знаний → Рубрикатор → Тема.

Метки описывают содержание и назначение материала; они не выдают доступ и не подтверждают выполнение серверных проверок.

Путь темы задаёт вложенность: сначала область, затем конкретный вопрос. Технический код метки стабилен; читаемое название и определение находятся ниже.

Входные данные, actor, объект, операция, ответ и отказы.

Код метки: topic_api_contracts.

• API ShariX Open: операции, доступ и взаимодействие модулей.
• Backend/dbsynce: синхронизируемые сущности.
• Webservice Running: локальные данные и исполнение заказа.
• Интеграции Open.
• Создание заказа через API: транзакция, ответ и внешние события.

Разделение модулей, продуктов и лицензионных областей.

Код метки: topic_architecture_boundaries.

• Архитектура ShariX Open.
• Владение моделями: где изменять данные ShariX Open.
• Компоненты и модули Open.
• Конструктор сервиса: закрытый компонент.
• Модули Open и их обязанности.
• Общие модули ShariX Open: публикация и передача ответственному.

Кто определяет данные и операции над ними.

Код метки: topic_architecture_models.

• Backend/dbsynce: синхронизируемые сущности.
• Webservice Running: локальные данные и исполнение заказа.
• Владение моделями: где изменять данные ShariX Open.
• Заказ, Ticket и PROCESS.
• Концепция сервиса и назначение цифровой координации.

Повторное использование общих шаблонов и поведения.

Код метки: topic_design_components.

• Design Template: как использовать общие элементы интерфейса.

Подписи, ввод, ошибки, focus и доступность.

Код метки: topic_design_forms.

• Design Template: как использовать общие элементы интерфейса.

Архивы исходников, версии и статические графы.

Код метки: topic_development_context.

• Архив исходников ShariX Open: получение и работа с Graphify.

Состав поставки, инструкции, совместимость и передача ответственности.

Код метки: topic_development_delivery.

• Как подготовить изменение и инструкцию для оператора.
• Как публиковать общий код ShariX Open и передавать изменение на проверку.
• Общие модули ShariX Open: публикация и передача ответственному.
• Приёмка изменений ShariX Open: проверки, миграции и результат.
• Разработка ShariX Open.

Репозитории, ветки, исходные commits и публикация.

Код метки: topic_development_git.

• Как публиковать общий код ShariX Open и передавать изменение на проверку.

Маршрут анализа и изменения продукта.

Код метки: topic_development_methods.

• Методология разработки и ведения знаний.
• Разработка ShariX Open.
• Разработка ShariX Open: от задачи до опубликованного изменения.
• Стандарты решений и изменений.

• Как поддерживать классификацию и рубрикатор.

Критерии, доказательства и ограничения приёмки.

Код метки: topic_development_verification.

• Как подготовить изменение и инструкцию для оператора.
• Как проверять сведения о коде, установке и планах разработки.
• Приёмка изменений ShariX Open: проверки, миграции и результат.
• Проверка изменений и критерии приёмки.
• Разработка ShariX Open: от задачи до опубликованного изменения.

Канонический workspace, генерация Python и происхождение файлов.

Код метки: topic_handlers_blockly.

• Обработчики ShariX Open: Blockly, Python и выполнение.

• ST_REQUEST в работе: обычное обращение и профильная проверка.

Заявки полномочий и безопасная обработка отказа.

Код метки: topic_handlers_permissions.

• ACCESS_REQUEST в DECLINED: контрольный срок и безопасная очистка.

• ACCESS_REQUEST в PENDING: рассмотрение запроса на право.

Запросы Relationship, требования и активация.

Код метки: topic_handlers_relationships.

• NEG_REQUEST в ACCEPTED: активация Relationship и срок закрытия.
• NEG_REQUEST в PENDING: решение по Relationship и граница API scope.
• Подача и обработка заявки партнёра.

Очередь, XMPP, события, defer и восстановление.

Код метки: topic_handlers_runtime.

• SERVICE_REQUEST в BOOKED: ожидание исполнителя и окно PENDING.
• SERVICE_REQUEST в TEMPLATE: черновик, действия клиента и напоминания.
• Исполнение заказа и процессы.
• Новая ST_REQUEST: ожидание, очередь и переход в ASSIGNED.
• Обработчики ShariX Open: Blockly, Python и выполнение.
• Сценарии ShariX Open: выбор процесса и проверка результата.

• ST_REQUEST-дубликат: ожидание решения о закрытии.

• Повторно открытая ST_REQUEST: ожидание назначения.

• ACCESS_REQUEST в PENDING: рассмотрение запроса на право.

• SERVICE_REQUEST в PRE_FORCEMAJEUER: ожидание внешнего решения.

Стандартные заявки и передача их по стадиям.

Код метки: topic_handlers_support.

• Новая ST_REQUEST: ожидание, очередь и переход в ASSIGNED.

• ST_REQUEST в работе: обычное обращение и профильная проверка.

• ST_REQUEST-дубликат: ожидание решения о закрытии.

• Повторно открытая ST_REQUEST: ожидание назначения.

Постоянные страницы, родители, связи и рубрикатор.

Код метки: topic_knowledge_navigation.

• ShariX Open: основы и карта базы знаний.
• База знаний ShariX Open.
• Методология разработки и ведения знаний.
• Сценарии ShariX Open: выбор процесса и проверка результата.

• Как поддерживать классификацию и рубрикатор.

Что подтверждено исходниками, проверкой сервера или согласованным правилом.

Код метки: topic_knowledge_source_evidence.

• Архив исходников ShariX Open: получение и работа с Graphify.
• Как проверять сведения о коде, установке и планах разработки.
• Проверка изменений и критерии приёмки.

Службы, предупреждения, зависимости и наблюдаемый результат.

Код метки: topic_operations_diagnostics.

• Эксплуатация ShariX Open.

Пользователи, зависимости и исходное состояние установки.

Код метки: topic_operations_environment.

• Установка ShariX Open: требования к среде и удобство настройки.

Подготовка, deploy, restart и проверка запуска.

Код метки: topic_operations_install.

• Установка ShariX Open: требования к среде и удобство настройки.
• Эксплуатация ShariX Open.

Предложение исполнителя, доступность и переход к подбору.

Код метки: topic_orders_assignment.

• SERVICE_REQUEST в BOOKED: ожидание исполнителя и окно PENDING.

• SERVICE_REQUEST в PRE_FORCEMAJEUER: ожидание внешнего решения.

Создание записи, размещение, предупреждения и повтор.

Код метки: topic_orders_creation.

• API ShariX Open: операции, доступ и взаимодействие модулей.
• SERVICE_REQUEST в TEMPLATE: черновик, действия клиента и напоминания.
• Создание заказа через API: транзакция, ответ и внешние события.

Workspace, Stage, материалы и локальный результат.

Код метки: topic_orders_execution.

• Webservice Running: локальные данные и исполнение заказа.

Допустимые действия, сохранённое состояние и смена владельца.

Код метки: topic_orders_lifecycle.

• SERVICE_REQUEST в BOOKED: ожидание исполнителя и окно PENDING.
• SERVICE_REQUEST в DONE: финализация оплаты и закрытие.
• SERVICE_REQUEST в TEMPLATE: черновик, действия клиента и напоминания.
• Заказ, Ticket и PROCESS.
• Создание заказа через API: транзакция, ответ и внешние события.
• Сценарии ShariX Open: выбор процесса и проверка результата.

• SERVICE_REQUEST в PRE_FORCEMAJEUER: ожидание внешнего решения.

Различие Orders, Ticket и локальных данных.

Код метки: topic_orders_model.

• Доменная модель заказов и исполнения.
• Заказ, Ticket и PROCESS.

Платёжное состояние и отдельный gate закрытия.

Код метки: topic_orders_payments.

• SERVICE_REQUEST в DONE: финализация оплаты и закрытие.

Проверка actor, объекта и области данных.

Код метки: topic_security_object_access.

• API ShariX Open: операции, доступ и взаимодействие модулей.
• Backend/dbsynce: синхронизируемые сущности.
• NEG_REQUEST в PENDING: решение по Relationship и граница API scope.

Предметное Permissions отличается от членства в группе.

Код метки: topic_security_permissions.

• ACCESS_REQUEST в DECLINED: контрольный срок и безопасная очистка.
• Подача и обработка заявки партнёра.

• ACCESS_REQUEST в PENDING: рассмотрение запроса на право.

Подготовка проверок и gate активации.

Код метки: topic_security_requirements.

• NEG_REQUEST в ACCEPTED: активация Relationship и срок закрытия.

• ST_REQUEST в работе: обычное обращение и профильная проверка.

Граница настройки процесса и её источников; закрытые детали остаются внутри.

Код метки: topic_service_configuration.

• Конструктор сервиса: закрытый компонент.

Предметное назначение услуги и цифровой координации.

Код метки: topic_service_model.

• ShariX Open: основы и карта базы знаний.
• Концепция сервиса и назначение цифровой координации.

Company, полномочия и договорные запросы.

Код метки: topic_service_partner_onboarding.

• Подача и обработка заявки партнёра.

• access_request — ACCESS_REQUEST: заявка предметного полномочия; не равна членству в LDAP/Django-группе.
• api_capability — Capability handler: узко разрешённая workflow-операция вместе с identity и object scope; не общий CRUD-доступ.
• blockly — Blockly workspace: типизированный редактируемый источник, из которого генерируется исполняемый Python.
• bpmn — BPMN: описательная схема участников, действий, событий и ожиданий; просмотрщик не исполняет обработчик.
• generated_python — Generated Python: полученный из канонического источника файл; соответствие проверяется повторной генерацией.
• grace_period — Контрольный срок: именованное ожидание от предусмотренного поля времени; не универсальный SLA-таймер.
• model_owner — Владелец модели: модуль, определяющий смысл, структуру и допустимые операции изменения данных.
• neg_request — NEG_REQUEST: заявка, сопровождающая Relationship; её статус и активность связи различаются.
• object_scope — Object scope: ограничение объекта областью данных, actor и текущим состоянием.
• order — Orders: общая запись заказа dbsynce; её ID отличается от Ticket ID.
• order_intent — Намерение заказа: запрос пользователя, переданный handler; relay-подтверждение не доказывает исполнения.
• payment_state — Платёжное состояние: данные выбранного платёжного владельца; success одного retry не заменяет gate закрытия.
• pending_at — pending_at: вычисленная временная граница перехода планового BOOKED-заказа к PENDING.
• permissions — Permissions: предметное полномочие пользователя, его статус и связанный запрос; отличается от членства в группе.
• provenance — Provenance: сведения об исходных файлах, генераторе и контрольных суммах; не заменяют поведенческую проверку.
• provider_offer — Provider: предложение исполнителя с пользователем, услугой, компанией и при необходимости ресурсом.
• relationship — Relationship: направленная связь user_who/user_whom с типом, областью компании и собственным статусом.
• requirements — Requirements: обязательные условия, доказательства и проверки, учитываемые перед доменным действием.
• service_request — SERVICE_REQUEST: Ticket жизненного цикла заказа.
• source_evidence — Свидетельство по исходникам: точная версия и прочитанная операция; не подтверждение установленного сервера.
• st_request — ST_REQUEST: стандартная заявка; в рассмотренных процессах в том числе запрос проверки. Не подменяет произвольный тип заявки.
• ticket — Ticket: типизированная заявка с lifecycle, событиями и ссылками на предметные данные.
• ticket_accepted — ACCEPTED: заявка принята; выполнение требований и активация связанного объекта проверяются отдельно.
• ticket_booked — BOOKED: размещённый заказ до следующего действия или перехода; это не подтверждение принятия исполнителем.
• ticket_closed — CLOSED: терминальное закрытие Ticket; не физическое удаление связанных данных.
• ticket_declined — DECLINED: отклонённый запрос или заказ; дальнейшие действия зависят от ticket_type.
• ticket_done — DONE: завершение работы/решение соответствующего типа Ticket; финансовое закрытие или активация имеют отдельные условия.
• ticket_pending — PENDING: именованная стадия Ticket; числовой код и допустимые действия зависят от ticket_type.
• ticket_template — TEMPLATE: существующий черновик заказа.

• ticket_in_process — IN_PROCESS — обращение ST_REQUEST находится в работе; профильная проверка определяется стабильным контрактом.
• ticket_duplicate — DUPLICATE — ST_REQUEST признан дубликатом; сам статус не означает переноса содержимого или закрытия.
• ticket_reopened — REOPENED — ST_REQUEST переоткрыт и ожидает нового решения о назначении; это не новая доменная попытка проверки.
• ticket_pre_forcemajeuer — PRE_FORCEMAJEUER — техническое имя проблемной стадии заказа, ожидающей внешнего разбора; написание сохранено как в коде.
• external_resolution — Внешний разбор — решение уполномоченного участника через канонические операции; observer лишь наблюдает состояние.
• verification_workflow — Профильный workflow — обработка document-verification-v1 или requirement-check-v1 через scoped API с доменным результатом.