Agent-ready интернет-магазин: репозиторий, который клиент развивает с AI-агентом

У интернет-магазина может быть свой домен, фирменный дизайн и оплаченная разработка — и всё равно не быть технологически самостоятельным. Один бизнес зависит от SaaS-платформы и её тарифов. Другой формально владеет исходниками, но не может изменить кнопку без команды, которая помнит, как устроен проект. В обоих случаях проблема одна: магазин нельзя безопасно развивать без владельца скрытого контекста.

Мы прошли через это на собственном fashion-магазине IWANT: перевезли его с InSales на свой движок, а затем собрали из опыта переиспользуемый пакет миграции. Один из его принципов — отдавать клиенту не просто работающий сайт, а agent-ready репозиторий вместе с контуром деплоя.

Agent-ready интернет-магазин — это клиентский репозиторий, в котором AI-агент или новый разработчик может понять архитектуру, внести ограниченное изменение, проверить его и подготовить к выпуску без устных знаний прежнего подрядчика. Production при этом защищён отдельными правами, проверками и человеческим подтверждением.

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

Коротко. Мы передаём четыре связанных актива: код, карту проекта, автоматические проверки и управляемый деплой. Если клиент владеет только архивом исходников, но не Git-организацией, облачным аккаунтом, DNS, базой, секретами и процедурой rollback, полной передачи ещё не произошло.

Содержание

• Что значит «магазин принадлежит клиенту»
• Три вида зависимости: SaaS, CMS и подрядчик
• Почему Cursor сам по себе не делает проект agent-ready
• Из чего состоит agent-ready репозиторий
• Как AI-агент меняет интернет-магазин
• Три режима развития одной кодовой базы
• Как мы передаём деплой клиенту
• Безопасный production: что агенту можно, а что нельзя
• Как agent-ready связан с переездом с InSales
• Что должно остаться у клиента после сдачи
• Границы подхода
• FAQ
• Итог

Что значит «магазин принадлежит клиенту»

Юридическое право на код — только первый слой. Для операционной самостоятельности бизнесу нужны ещё три.

Слой владения	Что должно быть у клиента	Что происходит без него
Код	Git-репозиторий, история изменений, лицензии зависимостей	исходники есть, но непонятно, что и почему менялось
Данные	доступ к production-базе, экспорт, резервные копии, политика хранения	магазин нельзя восстановить или перенести независимо
Инфраструктура	cloud/hosting, DNS, CDN, почта, аналитика на аккаунтах клиента	подрядчик фактически контролирует запуск и домен
Знание	карта проекта, runbook, контракты, команды проверки	новый исполнитель заново проводит археологию

Архив site-final-v7.zip не решает задачу. Он не показывает историю, не гарантирует воспроизводимую сборку и часто не содержит инфраструктурной конфигурации. Так же недостаточно создать репозиторий в личном аккаунте разработчика и «дать доступ»: владелец бизнеса должен иметь административные права, понятный порядок смены исполнителя и возможность отозвать чужие ключи.

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

1. Где находится исходный код и кто администратор репозитория?
2. Какими командами новый человек поднимает проект и проверяет изменение?
3. Где хранятся данные и как восстановить магазин из резервной копии?
4. Кто может выпустить версию в production и как её откатить?
5. Какие действия требуют обязательного человеческого ревью?

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

Три вида зависимости: SaaS, CMS и подрядчик

Здесь важно не смешивать разные модели. InSales, OpenCart и «1С-Битрикс: Управление сайтом» нельзя честно поставить в один ряд под заголовком «код не ваш».

SaaS-платформа

InSales — размещённая платформа: магазин работает на инфраструктуре сервиса, а бизнес управляет им через административную панель, шаблоны, приложения и API. Платформа поддерживает экспорт товаров, заказов и клиентов; её API позволяет читать и изменять объекты магазина. Это полезные каналы переносимости данных, но не полный исходный код самой платформы. Официальная документация прямо описывает импорт и экспорт и работу внешнего сервера через InSales API.

Плюс SaaS — быстрый запуск и готовая эксплуатация. Ограничение — вы развиваете магазин в рамках разрешённых точек расширения. AI-агент может менять шаблон или работать через API, но не может перепроектировать закрытое ядро платформы.

Open-source CMS

OpenCart — другой случай. Это свободная open-source e-commerce платформа, а официальный репозиторий распространяется по GPLv3. Код можно хранить у себя, разворачивать на своём сервере и изменять.

Но открытый код ещё не означает agent-ready. Проект может быть перегружен конфликтующими расширениями, ручными правками ядра и неописанными зависимостями. Тогда лок-ин возникает не на уровне лицензии, а на уровне конкретной сборки и человека, который знает её историю.

Коммерческая коробочная CMS

«1С-Битрикс: Управление сайтом» — коммерческий self-hosted продукт. После покупки клиент получает дистрибутив и может самостоятельно установить его на хостинге. Здесь зависимость связана не с отсутствием файлов как таковых, а с лицензией, архитектурой CMS, обновлениями, модулями и рынком специалистов.

Собственная кодовая база

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

Модель	Кто управляет ядром	Можно ли дать агенту весь проект	Главный риск зависимости
Hosted SaaS	поставщик платформы	нет, только разрешённые слои	тарифы, API и границы платформы
Open-source CMS	клиент и сообщество	да	хаотичная кастомизация и плагины
Коммерческая self-hosted CMS	вендор + клиентская команда	да, в рамках лицензии	обновления, модули, специфика экосистемы
Custom agent-ready	клиент	да	дисциплину репозитория нужно поддерживать

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

Почему Cursor сам по себе не делает проект agent-ready

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

На неподготовленной кодовой базе агент часто генерирует правдоподобно неправильное изменение. Код компилируется, интерфейс выглядит убедительно, но скрытый инвариант нарушен. В e-commerce это может означать двойное списание, неверный остаток, потерянный заказ или утечку персональных данных.

Agent-ready начинается не с выбора модели, а с уменьшения неоднозначности:

• правила проекта записаны рядом с кодом;
• одна задача решается одним узнаваемым паттерном;
• контракты между слоями типизированы;
• проверки запускаются одной командой;
• рискованные зоны помечены и защищены;
• инфраструктура отделяет предпросмотр от production;
• у каждого изменения есть обратимый путь.

TypeScript полезен здесь не как модный маркер стека, а как один из контуров обратной связи. По определению из официального Handbook, TypeScript статически проверяет программу до исполнения. Он ловит часть ошибок формы данных — например, несуществующее поле или несовместимый тип — ещё до запуска. Но типы не доказывают правильность цены, налогового правила или бизнес-процесса. Для этого нужны тесты и доменные инварианты.

Из чего состоит agent-ready репозиторий

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

1. Карта проекта

Первый файл отвечает не на вопрос «что это за бренд», а на вопрос «как безопасно работать».

В нём должны быть:

• назначение сервисов и каталогов;
• команды локального запуска;
• обязательные переменные окружения без значений секретов;
• команды typecheck, lint, test, build;
• правила работы с базой;
• список опасных зон;
• критерии готовности pull request;
• инструкция для staging и production;
• контакты ответственных за деньги, данные и инфраструктуру.

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

2. Сквозные типы и контракты

Товар проходит через базу, backend, API, storefront, чекаут, оплату, аналитику и админку. Если на каждом слое его форма описана отдельно, изменения начинают расходиться.

Поэтому критичные сущности — Product, Variant, Money, Cart, Order, Payment, Shipment, Customer — получают явные контракты. На внешних границах данные валидируются: типы TypeScript исчезают после компиляции и сами по себе не защищают runtime от некорректного webhook или импорта.

Особенно полезны доменные типы, которые не позволяют спутать похожие значения:

• цена в минимальных денежных единицах и форматированная строка;
• внутренний ID заказа и публичный номер;
• оплаченный заказ и авторизованный платёж;
• складской остаток и доступное к продаже количество;
• дата в UTC и локальное время пользователя.

3. Предсказуемые паттерны

Если один API endpoint валидирует вход на границе, второй — в сервисе, а третий доверяет любому JSON, агенту приходится угадывать правильный стиль. Чем больше вариантов, тем выше вероятность случайно выбрать слабый.

Мы уменьшаем разброс:

• одна структура feature-модуля;
• единый способ ошибок и логирования;
• один механизм авторизации;
• единый доступ к данным;
• повторяемые шаблоны тестов;
• централизованные интеграционные адаптеры;
• запрет на бизнес-логику внутри UI-компонентов.

Однообразие здесь не эстетика. Это средство управления вероятностью ошибки.

4. Замкнутый цикл проверки

Агент должен не только написать код, но и получить машиночитаемый ответ, что с ним не так.

Минимальный цикл:

1. форматирование и линт;
2. строгая проверка типов;
3. unit-тесты доменной логики;
4. интеграционные тесты API и базы;
5. сборка production-версии;
6. smoke-тест ключевого пути;
7. preview или staging для визуальной проверки.

Проверки не гарантируют отсутствие дефектов. Они превращают часть скрытых ошибок в конкретные сообщения, которые агент способен исправить самостоятельно.

5. Ограждение опасных зон

В репозитории явно отмечаем код, который нельзя менять и выпускать без человека:

• создание и подтверждение платежа;
• возвраты и повторные списания;
• права доступа и персональные данные;
• миграции с удалением или преобразованием данных;
• расчёт налогов и фискализация;
• массовая синхронизация остатков;
• production secrets и DNS;
• необратимые административные операции.

Для этих зон мало общей фразы «будь осторожен». Нужны CODEOWNERS/required review, отдельные тесты, минимальные права и запрет прямого push в production.

Как AI-агент меняет интернет-магазин

Нормальный сценарий выглядит как короткий инженерный цикл, а не как чат «сделай красиво».

1. Задача. Владелец описывает ожидаемый результат и критерии приёмки: например, добавить фильтр по наличию в конкретном магазине.
2. Разведка. Агент читает карту проекта, находит текущий фильтр, контракты каталога и существующие тесты.
3. План. До изменения перечисляет затронутые файлы, риски и проверки.
4. Реализация. Делает минимальный diff в существующем паттерне.
5. Самопроверка. Запускает типы, линт, тесты и сборку.
6. Preview. Создаёт изолированную версию для просмотра.
7. Ревью. Человек проверяет бизнес-смысл и UX, а для рискованной зоны — ещё и инженерную безопасность.
8. Выпуск. CI/CD разворачивает утверждённый commit, выполняет smoke-тест и сохраняет возможность rollback.

В этом процессе агент не получает бесконтрольный доступ к магазину. Он работает с изменением и доказательствами его корректности. Право выпустить версию — отдельная способность.

Три режима развития одной кодовой базы

Клиент не выбирает один режим навсегда. Одна кодовая база поддерживает три.

Своими силами через админку

Контент, товары, цены, акции, подборки, SEO-поля и операционные настройки меняются без разработки. Хорошая админка важнее попытки решить любую задачу кодом.

С AI-агентом

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

Полезно заранее установить лимит автономности:

• агент может читать весь код;
• может создать ветку и pull request;
• может запускать CI и preview;
• не может читать production secrets;
• не может самостоятельно подтвердить production deploy;
• не может выполнять destructive migration;
• не может менять оплату без профильного ревью.

Вместе с нами

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

Границу поддержки фиксируем заранее. Self-serve изменения клиента и ретейнер подрядчика — разные зоны ответственности. Если сторонний агент изменил checkout в обход процесса и это попало в production, такой инцидент не должен автоматически считаться SLA подрядчика. Иначе цена свободы незаметно перекладывается на того, кто не контролировал изменение.

Как мы передаём деплой клиенту

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

Базовый поток выглядит так:

commit → автоматические проверки → preview/staging → ручное подтверждение → production → smoke-тест → наблюдение → rollback при ошибке

Конкретный cloud может отличаться. Контракт остаётся тем же.

1. Инфраструктура оформлена на клиента

На стороне клиента должны находиться:

• GitHub/GitLab organization;
• cloud или hosting account;
• регистратор домена и DNS;
• production database и backup storage;
• CDN/object storage;
• почтовый и SMS-провайдер;
• платёжный кабинет;
• аналитика, error tracking и uptime monitoring.

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

2. Среды разделены

Local, preview, staging и production не должны делить одну базу и одни ключи. Preview использует тестовые интеграции. Staging повторяет production-архитектуру настолько, насколько оправдано стоимостью. Production принимает только утверждённые версии.

GitHub описывает environments как отдельные цели development, staging и production; для них можно ограничить ветки, доступ к секретам и потребовать approval. В официальной документации GitHub это встроенная модель управления deployment.

3. CI является пропускным пунктом

Прямая загрузка файлов по FTP исключается. Перед merge обязательны:

• типы;
• линт;
• тесты;
• production build;
• проверка миграций;
• dependency/security scan по выбранной политике;
• preview или staging smoke.

Protected branch не принимает изменение, пока required checks не пройдены. GitHub отдельно указывает, что при включённых required status checks защищённую ветку нельзя обновить с падающей обязательной проверкой.

4. Секреты не лежат в репозитории

Ключи оплаты, базы, почты и внешних API хранятся в secret manager или environment secrets. Агент видит имена переменных и тестовые значения, но не production credentials.

GitHub Actions позволяет хранить secrets на уровне организации, репозитория или конкретной среды. Environment secret становится доступен job только после прохождения защиты среды и approval — это описано в GitHub Secrets.

Одновременно действует принцип минимальных прав: deploy credential может развернуть приложение, но не обязан уметь удалить cloud-проект; storefront получает только те права к базе, которые нужны runtime.

5. Production требует человеческого подтверждения

Зелёный CI означает «известные автоматические проверки пройдены», а не «бизнес гарантированно согласен». Для production мы оставляем approval ответственному человеку. Для изменения оплаты или миграции добавляется профильный reviewer.

Агент может подготовить release note:

• что изменилось;
• какой commit выпускается;
• какие проверки пройдены;
• есть ли миграция;
• как проверить результат;
• как откатить.

Но подтверждение остаётся отдельным действием человека.

6. Миграции базы выпускаются отдельно от надежды

Самый опасный deploy — тот, где новый код несовместим со старой схемой, а миграция удаляет данные.

Безопасная модель предпочитает обратимые этапы:

1. добавить новую структуру без удаления старой;
2. выпустить код, который понимает обе версии;
3. перенести или backfill данные;
4. переключить чтение;
5. убедиться в корректности;
6. удалить старое поле отдельным поздним релизом.

Перед рискованной миграцией создаётся и проверяется backup. Rollback описывает не только возврат приложения на прежний image/commit, но и судьбу уже изменённых данных. Фраза «откатим Git» не восстанавливает удалённую колонку.

7. У релиза есть наблюдение и rollback

После deployment автоматически проверяются главная, каталог, карточка, корзина, создание тестового заказа и health endpoint. Команда видит ошибки, latency и ключевые бизнес-события.

Rollback должен быть заранее подготовленной операцией:

• предыдущий image или build остаётся доступен;
• версия конфигурации известна;
• команда отката документирована;
• миграция классифицирована как обратимая или необратимая;
• ответственный понимает, когда откатывать, а когда чинить вперёд.

Так деплой становится воспроизводимым процессом, который может обслуживать новая команда — и который AI-агент может безопасно подготовить, не получая право единолично управлять production.

Безопасный production: что агенту можно, а что нельзя

Удобно разделить возможности не по принципу «AI или человек», а по потенциальному ущербу.

Действие	Агент самостоятельно	Нужен человек	Дополнительная защита
изменить текстовый UI-блок	да, в ветке	review перед merge	preview + UI smoke
добавить фильтр каталога	да, в ветке	продуктовый review	типы + API/integration tests
обновить dependency	может подготовить PR	engineering review	lockfile, tests, security scan
изменить расчёт скидки	только подготовить	domain reviewer	сценарные тесты денег
изменить оплату/возврат	нет автономного выпуска	senior review + approval	sandbox payment, audit log
выполнить destructive migration	нет	DBA/ответственный инженер	backup, rehearsal, rollback plan
изменить DNS или production secret	нет	владелец инфраструктуры	MFA, least privilege, audit
задеплоить production	может подготовить release	required approval	protected environment

Самая важная мысль: способность написать изменение и право применить его — не одно и то же. Репозиторий можно сделать удобным для агента, не превращая production в открытую консоль.

Подробнее о выборе задач, где автономность действительно полезна, мы писали в материале «ИИ-агенты в бизнесе: где есть эффект, а где хайп». А связь AI-разработки с новыми командными ролями разобрана в статье «Что будет после AI: разработка без швов».

Как agent-ready связан с переездом с InSales

Agent-ready репозиторий — не отдельная косметическая услуга после миграции. Он получается из способа, которым строится сам переезд.

На опыте IWANT мы выделили шесть параллельных потоков.

1. Инвентаризация данных

Каталог — не только названия и цены. Нужно перечислить:

• товары, варианты, свойства и коллекции;
• изображения и файлы;
• остатки и склады;
• клиенты и согласия;
• заказы, статусы и история;
• промокоды и скидочные правила;
• SEO-поля;
• контентные страницы;
• интеграционные идентификаторы.

InSales предоставляет CSV/YML-экспорт и API, но каждая реальная выгрузка имеет свои поля, пропуски и исторические особенности. Поэтому перенос строится под конкретные данные, а не под идеальную схему из документации.

2. Карта URL и SEO

До запуска выгружаются старые URL и сопоставляются с новыми. Решение принимается не только по структуре каталога, но и по трафику, внешним ссылкам и ценности страницы.

Для изменившихся адресов настраиваются постоянные server-side redirects. Google рекомендует по возможности использовать 301 или 308 при постоянном переносе URL — это зафиксировано в руководстве Site Moves and Migrations.

Неправильная схема «все старые страницы → главная» теряет смысл соответствия. Товар ведёт на тот же товар, категория — на релевантную категорию, удалённая страница — на ближайший реальный аналог только когда он действительно существует.

3. Двойная проверка данных

Импорт считается завершённым не по сообщению «скрипт отработал». Мы сверяем количество и контрольные выборки:

• число товаров и вариантов;
• обязательные поля;
• цены и валюты;
• остатки;
• изображения;
• связи заказ–клиент;
• статусы;
• популярные URL;
• контрольные заказы.

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

4. Репетиция cutover

Переезд сначала проходит на staging. Команда измеряет длительность финальной синхронизации, проверяет redirects, интеграции, оплату, доставку, почту и аналитику. Затем фиксирует runbook запуска по минутам и ответственных.

Цель — не обещать «переключимся как-нибудь ночью», а заранее знать:

• когда прекращаются структурные изменения в старом магазине;
• какие данные синхронизируются последними;
• кто меняет DNS;
• кто проверяет оплату;
• какое условие запускает rollback;
• где фиксируются найденные проблемы.

5. Запуск без потери новых заказов

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

Конкретная техника зависит от API и архитектуры. Иногда возможна почти онлайн-синхронизация, иногда нужен короткий freeze на административные изменения. Честный план описывает это заранее.

6. Передача эксплуатации

После стабилизации клиент получает не только production URL. Он получает репозиторий, инфраструктуру, инструкции, доступы, backup/restore, release process и список известных ограничений.

Так миграция превращает магазин из услуги платформы в управляемый бизнес-актив.

Что должно остаться у клиента после сдачи

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

Код и знания

• [ ] Репозиторий находится в организации клиента.
• [ ] У клиента есть минимум два администратора.
• [ ] Сохранена история commit и решений, а не только архив.
• [ ] Есть карта архитектуры и каталогов.
• [ ] Есть команды запуска, тестов и сборки.
• [ ] Описаны доменные инварианты checkout, оплаты и остатков.
• [ ] Перечислены опасные зоны и обязательные reviewers.

Данные и инфраструктура

• [ ] Cloud, DNS и production database оформлены на клиента.
• [ ] Секреты отсутствуют в Git.
• [ ] Local/staging/production используют разные credentials.
• [ ] Настроены автоматические backups.
• [ ] Restore хотя бы один раз проверен на тестовой среде.
• [ ] Аналитика, error tracking и uptime доступны клиенту.

Разработка и деплой

• [ ] Pull request запускает typecheck, lint, tests и build.
• [ ] Production branch защищена от прямого push.
• [ ] Preview или staging создаётся до production.
• [ ] Production deploy требует approval.
• [ ] Миграции имеют отдельный review и план данных.
• [ ] Предыдущую версию можно восстановить по инструкции.
• [ ] После релиза запускается smoke-тест ключевого пути покупки.

Если 5–7 пунктов отсутствуют, проект, вероятно, ещё зависит от памяти исполнителя. Если отсутствуют права на инфраструктуру и rollback, зависимость уже операционная, даже при наличии исходников.

Границы подхода

Agent-ready не отменяет инженерную ответственность.

AI-агент не заменяет специалиста в критичных задачах

Сложная интеграция с 1С/ERP, безопасность, платежи, налоги, фискализация, архитектура высокой нагрузки и восстановление после инцидента требуют профильного человека. Агент ускоряет анализ и реализацию, но не получает автоматически опыт и ответственность.

Репозиторий деградирует без дисциплины

Карта проекта устаревает, тесты перестают отражать поведение, а исключения размножаются. Agent-ready — не сертификат навсегда. Каждое изменение должно сохранять предсказуемость системы.

Свой движок окупается не всем

Если бизнесу хватает платформы, доработки редки, а оборот не оправдывает собственную эксплуатацию, SaaS может быть экономически лучше. Платформа покупает скорость и снимает часть инфраструктурной нагрузки. Не нужно строить custom-систему ради статуса.

Передача контроля означает передачу обязанностей

Владея production, клиент отвечает за доступы, продление сервисов, резервные копии, безопасность и решения о релизах — самостоятельно или через договор поддержки. Контроль не бывает отдельно от операционной ответственности.

FAQ

Что такое agent-ready репозиторий?

Это репозиторий с актуальной картой проекта, предсказуемой архитектурой, типизированными контрактами, автоматическими проверками и описанным безопасным процессом выпуска. AI-агент может внести изменение и доказать, что известные проверки пройдены, но production остаётся защищённым.

Достаточно ли открыть существующий интернет-магазин в Cursor?

Нет. Редактор даст агенту доступ к файлам, но не создаст отсутствующие доменные правила, тесты, права, staging и rollback. На хаотичном проекте инструмент лишь быстрее производит изменения с неизвестным риском.

Может ли AI-агент сам деплоить магазин?

Технически может, но для production это плохая модель полномочий. Безопаснее разрешить агенту создать ветку, пройти CI, развернуть preview и подготовить release, а production запускать после человеческого approval.

Чем такой магазин отличается от OpenCart?

OpenCart уже предоставляет открытый исходный код и self-hosting. Отличие agent-ready подхода не в самом факте доступа к коду, а в конкретной сборке: контрактах, единых паттернах, тестах, документации, ограничении опасных зон и воспроизводимом deployment.

Чем он отличается от 1С-Битрикс?

«1С-Битрикс: Управление сайтом» — self-hosted коммерческая CMS с лицензией, дистрибутивом, модулями и своей экосистемой. Custom agent-ready репозиторий не зависит от архитектуры этой CMS, но требует самостоятельно поддерживать ядро, инфраструктуру и безопасность.

Что будет с SEO при переезде с InSales?

SEO-риск снижается, если до cutover собрать старые URL, сопоставить их с новыми, настроить релевантные 301/308, сохранить метаданные и контент, обновить sitemap/canonical и проверить приоритетные страницы после запуска. Полностью исключить временные колебания нельзя.

Кто отвечает, если агент клиента сломал production?

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

Итог

Собственный интернет-магазин — не синоним «самописного сайта». Это система, которой бизнес способен управлять при смене инструмента, агента или подрядчика.

На выходе должны быть:

1. код и история в репозитории клиента;
2. понятная карта проекта;
3. типы, тесты и повторяемые паттерны;
4. изолированные среды и защищённые секреты;
5. CI/CD с human approval;
6. backup, smoke-тест и rollback;
7. ясная граница ответственности.

Мы прошли переезд на собственном магазине IWANT и отдаём клиентам именно такую систему: ядро e-commerce, миграцию данных, SEO-карту, инфраструктуру и репозиторий, который можно развивать через админку, с AI-агентом или вместе с нами.

Если ваш магазин работает на InSales, «1С-Битрикс», OpenCart или конструкторе и вы хотите понять реальную степень зависимости, проведём бесплатный разбор. На нём разложим, что уже принадлежит бизнесу, чего не хватает для передачи, как выглядит миграция и где собственный движок действительно окупится.