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