Cors ошибка при запросе на API

Есть действующий production-сайт с каталогом товаров, карточками моделей и информационными страницами. Стек frontend: — Next.js; — React; — TypeScript; — существующая компонентная система; — staging и production environments. Есть согласованное визуальное направление и дизайн новой главной страницы. Необходимо внедрить его в существующий проект, адаптировать под desktop/tablet/mobile и привести все основные типы страниц сайта к единой обновлённой стилистике. Полный редизайн продукта и изменение бизнес-логики не требуются. ОБЯЗАТЕЛЬНЫЙ SCOPE 1. Новая главная страница — реализовать главную страницу по предоставленному дизайну; — сохранить существующую функциональность, ссылки и маршрутизацию; — корректно подключить согласованные секции и CTA; — использовать существующие данные и API; — предусмотреть корректное отображение динамического контента. Основные типы секций: — header/navigation; — hero; — информационные блоки; — карточки моделей/предложений; — аналитические или market insight блоки; — CTA-секции; — footer. Точный состав секций будет предоставлен выбранному исполнителю вместе с макетом. 2. Responsive Необходимо реализовать: — desktop; — tablet; — mobile; — промежуточные разрешения; — корректное поведение сеток, карточек, меню, кнопок и типографики; — отсутствие горизонтального скролла и визуальных конфликтов. 3. Типографика и общие стили — внедрить новые согласованные шрифты; — привести размеры, веса, line-height и интервалы к единой системе; — обновить стили кнопок, карточек, полей, бейджей и заголовков; — по возможности использовать общие design tokens или CSS variables; — не дублировать стили отдельно для каждой страницы без необходимости. 4. Унификация существующих страниц Проверить и привести к новой стилистике основные типы страниц: — каталог; — карточка модели / PDP; — информационные страницы; — header; — footer; — формы; — модальные окна; — существующие CTA; — loading / empty / error states, если они уже присутствуют в проекте. Речь идёт о визуальной унификации существующих компонентов, а не о полном индивидуальном редизайне каждой страницы. 5. Каталог Проверить: — сетку карточек; — изображения; — название, reference и цену; — фильтры и сортировки; — кнопки и ссылки; — desktop/mobile отображение; — loading и empty states; — отсутствие визуальных сдвигов при загрузке. 6. PDP Проверить: — галерею; — основной информационный блок; — цену и CTA; — аналитические секции; — таблицы и метрики; — About Watch; — desktop/mobile компоновку; — длинные названия, references и отсутствующие данные. Необходимо сохранить текущую функциональность и существующие контракты API. 7. Header и Footer — единая стилистика на всех страницах; — responsive navigation; — mobile menu; — корректные active/hover/focus states; — отсутствие расхождений между главной, каталогом и PDP. 8. Состояния интерфейса Для динамических блоков проверить: — loading; — empty data; — API error; — insufficient data; — отсутствующее изображение; — отсутствующая цена; — длинный текст; — мобильное отображение. Не требуется разрабатывать новую сложную бизнес-логику. Необходимо корректно визуализировать уже существующие состояния. 9. Качество и производительность — не ухудшить SEO и текущую индексацию; — сохранить корректные metadata и semantic HTML; — не создавать критических layout shifts; — оптимизировать изображения и шрифты; — учитывать reduced motion для анимаций; — проверить базовую доступность: focus states, contrast, keyboard navigation; — не подключать тяжёлые библиотеки без обоснованной необходимости. 10. Staging и QA — развернуть изменения на staging; — проверить основные типы страниц; — проверить desktop, tablet и mobile; — устранить визуальные и responsive-баги; — после приёмки выполнить production deployment; — обеспечить исправление багов по реализованному scope не менее 7 календарных дней после выкладки. РЕЗУЛЬТАТ РАБОТЫ — Pull Request с frontend-кодом; — реализованная новая главная; — responsive desktop/tablet/mobile; — единые шрифты, карточки и базовые UI-компоненты; — визуально согласованные каталог, PDP и информационные страницы; — staging deployment; — исправление найденных визуальных ошибок; — production deployment; — краткое описание изменённых компонентов; — 7-дневный bug-fix period после приёмки. ACCEPTANCE CRITERIA 1. Главная соответствует предоставленному дизайну. 2. Все секции корректно работают на desktop, tablet и mobile. 3. Header и footer единообразны на всех страницах. 4. Каталог и PDP визуально соответствуют новой системе. 5. Текущая функциональность сайта не нарушена. 6. API-контракты и backend-логика не изменены без согласования. 7. Нет горизонтального скролла и критических layout shifts. 8. Шрифты и изображения загружаются корректно. 9. Loading, empty и error states отображаются без поломки layout. 10. Изменения проверены на staging и развернуты в production. 11. Исправлены визуальные ошибки, обнаруженные при приёмке в рамках согласованного scope. ЧТО НЕ ТРЕБУЕТСЯ — разработка backend; — изменение бизнес-логики; — создание нового каталога или CMS; — разработка нового API; — полный редизайн каждой информационной страницы; — новые пользовательские функции, отсутствующие в макетах; — разработка сложной дизайн-системы с нуля; — создание нового проекта вместо доработки существующего; — изменение SEO-структуры без отдельного согласования. ТРЕБОВАНИЯ К ИСПОЛНИТЕЛЮ — уверенный Next.js / React / TypeScript; — опыт работы с существующими production-проектами; — качественная responsive-вёрстка; — опыт внедрения дизайна из Figma; — компонентный подход; — уверенная работа с CSS / CSS Modules / Tailwind или существующей системой проекта; — понимание Core Web Vitals; — Git / Pull Request workflow; — умение работать через staging. В ОТКЛИКЕ ОБЯЗАТЕЛЬНО УКАЗАТЬ 1. Fixed price за полный обязательный scope. 2. Срок выполнения в рабочих днях. 3. Оценку в часах. 4. Когда готовы начать. 5. Ссылки на 2–3 релевантных проекта на Next.js/React. 6. Есть ли опыт работы с каталогами, карточками товаров или аналитическими интерфейсами. 7. Что потребуется для точной оценки до начала работы. 8. Входят ли в цену: — staging; — responsive QA; — production deployment; — исправление багов; — 7-дневный bug-fix period. Шаблонные отклики без просмотра требований и без конкретной оценки рассматриваться не будут. Доступ к production на первом этапе не предоставляется. Работа начинается после ограниченного code review и разворачивается через staging.

Есть действующая production-платформа с каталогом и автоматическим обновлением внешних предложений и цен. Стек: — Node.js / TypeScript; — PostgreSQL; — существующий price refresh service и cron; — отдельный готовый Python-модуль валидации и выбора предложений; — staging и production. Необходимо точечно доработать существующий price refresh pipeline без полного переписывания backend. ОБЯЗАТЕЛЬНЫЙ SCOPE 1. Интеграция Python-модуля — Python-модуль остаётся отдельным компонентом; — возвращает структурированный результат: offers, selected offer, statuses и risk flags; — Node.js валидирует результат и выполняет запись в БД; — предусмотреть обработку ошибок и partial/failed runs; — legacy pipeline не отключается до завершения QA. 2. Запуск refresh по списку Добавить запуск: — по одному slug/id; — по переданному списку slug/id. Допустим CLI или существующий служебный API. Новый пользовательский интерфейс не требуется. 3. Shadow Mode Новые результаты должны записываться отдельно и не влиять на production до QA. Требуются shadow-поля: — price; — selected offer ID; — direct URL; — offer status; — risk/QA flags; — checkedAt; — engineVersion. 4. Расширение существующей таблицы offers Добавить: — source; — external_offer_id; — last_seen_at; — last_checked_at; — engine_version; — risk flags либо хранение в существующем JSON; — unique constraint для защиты от дублей. Новую параллельную offer-систему создавать не требуется, если существующую таблицу можно безопасно расширить. 5. UPSERT, STALE и DB transaction Заменить текущую схему DELETE → CREATE: — UPSERT существующих и новых offers; — отсутствующие в полном успешном snapshot offers переводятся в STALE; — при API error, partial result или незавершённом snapshot активные offers не должны становиться STALE; — обновление offers, selected offer metadata и shadow fields по одной модели выполняется внутри одной DB transaction; — при ошибке выполняется полный rollback. 6. Canonical-safe refresh Price refresh не должен изменять: — brand; — reference; — model; — collection; — name/title; — slug; — descriptions; — images; — SEO fields. Обновляются только offer, price и shadow data. 7. Сохранение текущей cron-логики Сохранить: — existing cron; — rolling batches; — cooldown; — проверку PRICE_REFRESH_MIN_DAYS до вызова внешнего API; — legacy production pipeline до завершения Shadow QA. 8. Audit output Достаточно одного варианта: — shadow-колонки в существующей admin table; или — CSV export. Минимальные данные: — model/reference; — production price; — shadow price; — delta; — production/shadow URL; — status; — risk flags; — checkedAt; — engineVersion. Новый сложный dashboard не требуется. 9. Staging и QA — DB migrations; — staging deployment; — smoke test на 5 переданных моделях; — затем Shadow Mode приблизительно на 50 моделях; — исправление технических ошибок, выявленных во время этих прогонов; — краткая документация контракта Python → Node.js и rollback procedure. ОПЦИОНАЛЬНО ОЦЕНИТЬ ОТДЕЛЬНО Простой технический promotion без нового UI: — promotion одной модели по slug; — promotion списка slug; — перенос подтверждённых shadow values в production; — техническая проверка после rollout. РЕЗУЛЬТАТ — Pull Request; — DB migrations; — рабочая интеграция Python → Node.js; — Shadow Mode; — UPSERT, STALE и транзакционное обновление; — запуск по slug/id; — staging deployment; — smoke-test results; — краткая документация; — не менее 7 дней исправления багов по реализованному scope после приёмки. В ОТКЛИКЕ УКАЗАТЬ 1. Fixed price за обязательный scope. 2. Отдельную стоимость promotion-механизма. 3. Срок. 4. Оценку часов. 5. Когда готовы начать. 6. Опыт с PostgreSQL transactions, migrations и ingestion pipelines. 7. Какие вопросы нужно уточнить до начала. 8. Включены ли staging, QA, migrations и bug-fix period. Шаблонные ответы без конкретной оценки рассматриваться не будут. Доступ к production на первом этапе не предоставляется. Работа начинается с ограниченного code review и staging.

Доброго дня , 1) обновить jQuery** до актуальной версии (3.x) с подключением jQuery Migrate 2) Тщательно протестируйте функциональность приложения 3) и устранить возможные ошибки чтобы скрипты все были совместимы между собой по версиям здесь нужно полностью переписыватьhttps://filtry.in.ua/assets/libs/libs.js под новую версию jquery так как там и бутстрап старый и много функций кастомных прописано

Описание: Необходимо создать JavaScript-скрипт для расширения Tampermonkey. Скрипт будет работать во внутренней рабочей CRM-системе.Логика работы: Скрипт должен считывать уникальный текстовый ID текущего активного диалога на странице (всего есть 5–10 различных ID). В зависимости от ID, скрипт берет соответствующую текстовую инструкцию (System Prompt) из настроек. Карта параметров по ID должна быть вынесена в отдельное удобное окно настроек скрипта. При появлении нового сообщения в окне чата, скрипт отправляет этот текст вместе с промптом через API OpenAI (модель gpt-4o-mini). Полученный ответ скрипт вставляет в поле ввода текста и инициирует отправку с рандомной задержкой в 20–45 секунд для имитации естественной работы оператора.Работа сугубо с текстом. Бюджет — 6000 грн. Жду предложений от разработчиков с опытом работы с OpenAI API и написанием скриптов автоматизации браузера.

Необходимо разработать собственный веб-сервис для автоматизации работы кофеен и небольших заведений общественного питания. По функциональности продукт должен быть похож на Poster POS, но с собственным дизайном, архитектурой и программным кодом. Копирование кода или интерфейса Poster не предполагается. Планируется создание полноценного коммерческого SaaS-продукта, которым в будущем смогут пользоваться различные кофейни по подписке.На первом этапе нужно разработать MVP Основной функционал: регистрация и авторизация владельца заведения; создание одного или нескольких заведений; управление сотрудниками и ролями; каталог товаров, категорий и модификаторов; добавление размеров, вкусов и дополнительных опций; кассовый интерфейс для оформления продаж; открытие и закрытие кассовой смены; разные способы оплаты; возврат и отмена заказов; учет остатков и списание товаров; базовый складской учет; история продаж; отчеты по выручке, товарам, сменам и сотрудникам; программа лояльности для клиентов; адаптивная работа на планшете, ноутбуке и смартфоне; административная панель владельца сервиса; тарифные планы и ограничения в соответствии с тарифом.В дальнейшем планируется мобильное приложение; интеграция с платежными терминалами; печать чеков; интеграция с фискальными сервисами; доставка и онлайн-заказы; бронирование столиков; расширенная аналитика; API для сторонних интеграций; интеграция с бухгалтерскими и CRM-системами.Важные требования система должна быть рассчитана на работу многих независимых заведений; данные каждого клиента должны быть изолированы; необходимо предусмотреть масштабирование продукта; нужна безопасная работа с финансовыми и персональными данными; код должен быть структурированным и пригодным для дальнейшего развития; нужна техническая документация; права на исходный код после оплаты передаются заказчику. Дизайн на данный момент отсутствует, поэтому нужно отдельно оценить UI/UX-дизайн или предложить готовое решение для MVP.В предложении укажите опыт создания SaaS, POS, CRM, ERP или учетных систем; примеры подобных работ; предложенный стек технологий; состав команды; ориентировочную стоимость MVP; срок разработки; что именно входит в предложенную стоимость; стоимость дальнейшей поддержки; готовы ли работать поэтапно с оплатой за каждый завершенный этап. Преимущество исполнителям или командам, которые уже разрабатывали кассовые, складские, ресторанные или многопользовательские SaaS-системы.