Shop-Script в облаке или на своём сервере выбирают вместе с ответственным за изменения

В облаке Webasyst Shop-Script уже установлен, серверы администрирует поставщик. Можно редактировать HTML и CSS, но нет FTP-доступа и прямого доступа к базе. Поэтому просьба «дать агенту FTP-доступ и поручить доработать PHP-код» не описывает выполнимую облачную задачу.

Это не запрет на развитие магазина. Сначала проверьте готовое расширение, тему или интеграцию через API. Если нужен частный плагин, до заказа уточните у Webasyst способ его установки и ограничения. Разница между «платформа поддерживает плагины» и «наш плагин можно выпустить в этом аккаунте» обнаруживается на конкретной доработке.

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

Свой сервер в документации Shop-Script означает и подходящий сторонний хостинг. Покупать оборудование необязательно. Вы получаете доступ к PHP-коду, базе и конфигурации, а вместе с ним организуете установку, администрирование, права доступа и запуск заданий по расписанию.

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

Сравнивайте поставки на одной задаче. У исполнителя должны быть ответы: куда попадёт код, как его установить, кто проверит совместимость и кто восстановит работу. Если подрядчик описывает только установку Shop-Script, развитие магазина и обслуживание сервера пока остаются без исполнителя.

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

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

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

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

Инженер ведёт машину агентов: выбирает место изменения, выдаёт доступы, принимает код и решает, можно ли выпускать его. Агент может подготовить расширение и проверки. Менеджер магазина подтверждает, что сценарий соответствует работе продаж. Эти роли надо назвать до доработки, чтобы после ошибки не искать того, кто разрешил выпуск.

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

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

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

Последний вопрос перед выпуском: кто заметит, что оформление заказа перестало работать? Успешный запуск сервера этого не доказывает. Назначьте исполнителя проверки после выпуска и получателя сигнала об ошибке. Если нужен ночной дежурный, договоритесь о нём отдельно от очереди разработки.

В нашей машине правила проверки появились из ошибок. Лента ниже связывает каждую поломку с проверкой, которая осталась после ремонта. Истории относятся к vibecoding.ru, не к Shop-Script: они помогают выбрать порядок сопровождения, но не доказывают надёжность платформы магазина.

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

В открытой программе агентной разработки есть уроки «Где хостить» и «Руль, окно и сторож». Для магазина эта связка означает записанные правила изменения, видимый результат и сигнал отказа с адресатом. После ремонта инженер добавляет обнаружение повторной ошибки и проверяет, что сигнал доходит до исполнителя.

Если у собственного экземпляра есть постоянная очередь изменений, можно обсуждать разработку магазина по подписке. На 08.10.2026 «Один проект» стоит 250 000 ₽ в месяц: инженер ведёт машину агентов, задачи идут по очереди, код попадает в вашу ветку в вашем репозитории. Подписку можно поставить на паузу в любой месяц.

Это плата за развитие проекта. Лицензии, хостинг и сторонние сервисы считайте отдельными строками. Ночные дежурства и архитектура на странице услуги оставлены клиенту. До старта согласуйте, какие доработки Shop-Script попадут в очередь и кто будет принимать их и обслуживать сервер. Наш опыт vibecoding.ru не заменяет такую договорённость.

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

1. Выбирайте поставку по ближайшим доработкам и доступному способу их установки.

2. До своего хостинга назначьте ответственных за сервер, выпуск и восстановление.

3. Сначала ищите расширение или API. Зависимость от правки ядра принимайте явно.

4. Принимайте изменение по целому заказу и проверяйте сохранность новых покупок при восстановлении.

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