Программу ремонта техники дополняют агентами: серийный номер связывает приёмку, детали и выдачу

Сначала стоит проверить возможности своей программы. Приём-в-ремонт уже описывает сеть мастерских, приём и выдачу, документы и связь со складом запчастей.

Учёт обслуживания оборудования связывает план работ, конкретную единицу и подтверждённое выполнение.

Repair-CRM ведёт историю отдельного оборудования и заказы с фото и деталями. Его публичные страницы посвящены выездному сервису. Это соседний класс системы.

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

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

Если этот путь уже проходит без ручных пересказов, доработка не нужна. Если фото осталось у приёмщика, а выдающий сотрудник видит только «готово», найден предмет заказа.

Переписывание всей системы обсуждается отдельно в разборе технического долга. Выбор своей системы вместо коробки разобран в статье о своей CRM.

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

В предлагаемой модели устройству присваивают внутренний номер. Заводскую маркировку сохраняют рядом с моделью и фото, а каждое обращение открывают отдельным ремонтом.

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

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

Передачу подтверждают обе стороны. Пока мастерская не приняла аппарат, журнал показывает его в пути. Статус «отправлен» не означает «получен в полном комплекте».

Деталь связывают с ремонтом в момент установки. Резерв на складе ещё не доказывает, что узел поставили в пылесос. Возврат неиспользованной детали записывают отдельно.

Фото при приёмке даёт выдающему сотруднику исходную точку сравнения. Если шланг вернулся отдельно, его добавляют в итоговый комплект. Галочка «ремонт готов» эту сверку не заменяет.

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

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

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

Для разработки хватит вымышленных устройств и комплектов с нужными ошибками. Граница доступа к рабочим данным разобрана в статье о персональных данных и ИИ-агентах.

Наш опыт здесь относится к передаче данных внутри vibecoding.ru. Мы уже исправляли ситуацию, когда поле сохранялось в одном месте и не доходило до другого.

Для ремонта из этой истории следует правило. Комплект должен одинаково доходить до приёмки, мастерской и выдачи. Копия поля в каждом экране создаёт повод для расхождения.

На /open показаны 387 тысяч строк описаний и 391 тысяча строк кода, снимок 07.10.2026. Это объём нашего сайта, не оценка будущей программы сервисного центра.

Описание правил остаётся рядом с кодом. Такой подход разбираем в уроке «Файл правил целиком» курса агентной разработки и в статье о правилах для агентов.

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

Двойное нажатие «передать» не должно создавать две передачи. Если связь пропала после записи, повторная отправка должна находить уже сохранённое событие.

Проверяющий ищет аппарат с неправильным номером, неполный комплект и незакрытый переход. Для каждой ситуации до работы записывают ожидаемый ответ программы.

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

У действующей программы сначала проверяют API и выгрузку. Если записи обратно нет, отдельный журнал нельзя выдавать за двустороннюю связь с коробкой.

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

Первый заказ можно ограничить журналом устройства, фото комплекта и сверкой выдачи. Это один продукт с общей моделью данных, который разбивают на последовательные задачи.

«Один проект» на /services стоит 250 000 ₽ в месяц на 07.10.2026. Инженер ведёт машину агентов и сдаёт правки в репозиторий клиента.

В потоке выполняется одна задача, остальные ждут. Подписку можно поставить на паузу в любой месяц.

Срок считают после проверки кода и способов подключения. Очередь и приёмка влияют на него отдельно; это разобрано в статье о сроках разработки.

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

1. Начните с демонстрации своего маршрута в готовой программе. Заказывайте доработку найденного разрыва.

2. Сохраняйте внутренний номер устройства, проверенную маркировку и отдельную историю каждого ремонта.

3. Приёмку, передачу, установку и выдачу связывайте событиями. Неполный комплект оставляйте видимым до разбора.

4. Принимайте доработку на ошибках и повторных действиях. Код и правила сохраняйте у себя, а найденные разрывы возвращайте в очередь задач.