Полномочия, одобрение и восстановление
Предлагаемый контракт исполнения; не реализован. Это требования, которые нужно доказать, а не гарантии действующей платформы.
Продавец одобряет конкретные изменения, а система обеспечивает границы этого одобрения независимо от слов модели. Одобрение — ограниченное разрешение, а не реплика «выглядит хорошо».
Начальная модель разрешений
| Операция | Правило пилота |
|---|---|
| Читать разрешённые поля товаров и остатков | После согласия на подключение; границы магазина и роли проверяются в каждом запросе |
| Читать статус заказа | Минимум полей, права сотрудника, скрытые лишние данные покупателей |
| Готовить черновик или предложение | Разрешено без внешних побочных эффектов |
| Менять базовые цены | Явное одобрение ограниченной версионированной задачи и ограничения для каждой строки |
| Публиковать описания или менять остатки | Не входит в первый платный процесс |
| Возвраты денег, удаление, отправка, сообщения покупателям, изменение налогов или ключей | Не предоставляются как исполняемые инструменты MVP |
| Регулярная автоматическая запись | Позже, по отдельному согласию, после проверки типа задачи и восстановления |
Чтение тоже имеет риски: заказы и ключи требуют изоляции и контроля доступа. Недоверенные описания, файлы и ответы инструментов — данные, а не инструкции, расширяющие права.
Жизненный цикл исполнения
Черновик → проверенное предложение → одобренная версия → исполнение → проверенный отчёт. Дополнительные состояния: отклонено, срок истёк, отменено, заблокировано, частично выполнено, ожидает сверки.
Одобрение фиксирует магазин, пользователя, точные ID, значения до/после, валюту, налоги, формулу, лимиты и срок. Любые изменения отменяют одобрение. Перед каждой записью повторно проверяются права, текущие значения и срок. Устойчивый ключ операции идентифицирует то же изменение при повторных попытках.
Коннектор должен обеспечивать условную запись, где это возможно. Отдельной проверки перед несвязанной записью недостаточно, если вмешивается другой администратор или фид. Нужно проверить хуки, транзакции и конкурирующие записи на поддерживаемой версии. Без надёжного выявления конфликтов этот тип записи в пилоте не включается.
Поведение при сбоях — часть продукта
| Событие | Требуемое поведение |
|---|---|
| Артикулу соответствуют несколько товаров | Запросить решение или исключить строку, не угадывать цель |
| Администратор или ERP изменил цену после просмотра | Пропустить как конфликт; новое предложение требует нового одобрения |
| Тайм-аут после отправки записи | Пометить неопределённым, сверить журнал и свежее чтение; не повторять слепо |
| Часть строк успешна, часть нет | Сохранить состояние каждой; повторять лишь подходящие нерешённые строки |
| Владелец нажал «Стоп» | Отменить очередь и новые изменения, сверить запросы в полёте |
| Ключ отозван или права сужены | Запретить последующие операции, сохранить исторический отчёт |
| Устаревшее подключение | Показать время последнего чтения, не выдавать кеш за текущие данные |
Что означает отмена
Компенсирующее изменение цены восстанавливает старое значение лишь если текущее всё ещё равно записанному этой задачей, разрешение действует и продавец одобрил компенсацию. «Отмена» не должна перезаписывать более позднюю ручную правку. Восстановление поля не стирает оформленные заказы, отправленные сообщения или другие последствия.
Аудит и работа с информацией
Сохранять ссылку/контрольную сумму входа, версию сопоставления, разницу, результат политик, кто и когда одобрил, попытки, ответы платформы и повторно прочитанные значения. Не включать секреты в промпты и отчёты. Минимизировать данные покупателей до доступа модели; до пилота определить сроки хранения, удаление/экспорт и правила провайдера модели.
Нужны тесты изоляции клиентов, лимиты файлов и запросов, разрешённый список подключений. Недоступность магазина не должна включать неограниченный браузинг, прямой SQL или запасной пароль администратора.
План реализации возлагает контроль на сервис исполнения и коннектор, а не промпт.