Парсер Яндекс-маркета

Є діючий production-сайт з каталогом товарів, картками моделей та інформаційними сторінками. Стек frontend: — Next.js; — React; — TypeScript; — існуюча компонентна система; — staging та production середовища. Є погоджене візуальне напрямок і дизайн нової головної сторінки. Необхідно впровадити його в існуючий проект, адаптувати під 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 після приймання. КРИТЕРІЇ ПРИЙМАННЯ 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. Фіксована ціна за повний обов'язковий 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; — існуючий сервіс оновлення цін і cron; — окремий готовий Python-модуль валідації та вибору пропозицій; — staging і production. Необхідно точково доопрацювати існуючий pipeline оновлення цін без повного переписування backend. ОБОВ'ЯЗКОВИЙ СКОП 1. Інтеграція Python-модуля — Python-модуль залишається окремим компонентом; — повертає структурований результат: offers, selected offer, statuses та risk flags; — Node.js валідує результат і виконує запис у БД; — передбачити обробку помилок і partial/failed runs; — legacy pipeline не відключається до завершення QA. 2. Запуск оновлення за списком Додати запуск: — по одному 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 для захисту від дублів. Нову паралельну систему пропозицій створювати не потрібно, якщо існуючу таблицю можна безпечно розширити. 5. UPSERT, STALE і транзакція БД Замінити поточну схему DELETE → CREATE: — UPSERT існуючих і нових пропозицій; — відсутні в повному успішному snapshot пропозиції переводяться в STALE; — при API error, partial result або незавершеному snapshot активні пропозиції не повинні ставати STALE; — оновлення пропозицій, metadata вибраної пропозиції та shadow fields по одній моделі виконується всередині однієї транзакції БД; — при помилці виконується повний rollback. 6. Canonical-safe 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. Фіксована ціна за обов'язковий scope. 2. Окрему вартість механізму promotion. 3. Термін. 4. Оцінку годин. 5. Коли готові почати. 6. Досвід з PostgreSQL transactions, migrations та ingestion pipelines. 7. Які питання потрібно уточнити до початку. 8. Включені чи staging, QA, migrations та період виправлення помилок. Шаблонні відповіді без конкретної оцінки розглядатися не будуть. Доступ до 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-системи.