Google maps API

This is an unfinished plugin for After Effects: https://drive.google.com/drive/u/0/folders/1Nq9a672OK6ep9Com1lqelUhZxbx3_3f1 If I understand correctly, this is a CEP plugin (Adobe Extension) for After Effects. It is an HTML/JavaScript panel through Adobe CSXS that interacts with After Effects via ExtendScript. The goal was to automate the video creation process in the "maze challenge" style, reference on YouTube GOALRUSH-f8x or similar. Manually edited video: https://drive.google.com/file/d/1Ylzvax6w2JGDwaBqeCdbD49jh5wB5buY/view?usp=sharing File of one of the projects: https://drive.google.com/file/d/15vKd1L9VfHtDqK2wtLQdYEmDpH1d8Jvy/view?usp=sharing Besides the "bugginess" of the system due to vibe coding (so vibe coders are out), such details did not suit the device (real edits): https://docs.google.com/spreadsheets/d/18Svc6GoQ34PgLe1HY7gNX5tPLH0Cpv9E4mfjCRBCMFU/edit?gid=0#gid=0 It is necessary to create a system that will generate projects in After Effects with all the necessary video components listed in Base.pdf, more detailed logic in the form of photos, text documents, and mind maps for understanding all possible variations on the disk: https://drive.google.com/drive/folders/1Uf4Pnw3SKmwpmhL7sjPZFnfAbN0arUjr?usp=sharing Even more detailed (with a more in-depth descriptive part and links to time codes in references) the technical specifications will be finalized in the project workspace The final result is a system that creates videos: from 40 seconds to 1 minute, completely unique content for each creation, without AI metadata in the video file, it should have a clear plot (traps, dead ends, various emotions of celebrity characters as a result of some plot twists in the video), sound design according to the plot (screams and other emotions, explosions, etc.), stylistically not differing from the reference video from the channel.

There is an active production site with a product catalog, model cards, and informational pages. Frontend stack: — Next.js; — React; — TypeScript; — existing component system; — staging and production environments. There is an approved visual direction and design for the new homepage. It is necessary to implement it into the existing project, adapt it for desktop/tablet/mobile, and bring all main types of pages on the site to a unified updated style. A complete redesign of the product and changes to business logic are not required. MANDATORY SCOPE 1. New homepage — implement the homepage according to the provided design; — maintain existing functionality, links, and routing; — correctly connect approved sections and CTAs; — use existing data and APIs; — ensure correct display of dynamic content. Main types of sections: — header/navigation; — hero; — informational blocks; — model/offering cards; — analytical or market insight blocks; — CTA sections; — footer. The exact composition of sections will be provided to the selected performer along with the layout. 2. Responsive It is necessary to implement: — desktop; — tablet; — mobile; — intermediate resolutions; — correct behavior of grids, cards, menus, buttons, and typography; — absence of horizontal scrolling and visual conflicts. 3. Typography and general styles — implement new approved fonts; — unify sizes, weights, line-height, and spacing; — update styles for buttons, cards, fields, badges, and headings; — use common design tokens or CSS variables where possible; — avoid duplicating styles separately for each page unnecessarily. 4. Unification of existing pages Check and bring to the new style the main types of pages: — catalog; — model card / PDP; — informational pages; — header; — footer; — forms; — modal windows; — existing CTAs; — loading / empty / error states, if they are already present in the project. This is about the visual unification of existing components, not a complete individual redesign of each page. 5. Catalog Check: — card grid; — images; — name, reference, and price; — filters and sorting; — buttons and links; — desktop/mobile display; — loading and empty states; — absence of visual shifts during loading. 6. PDP Check: — gallery; — main information block; — price and CTA; — analytical sections; — tables and metrics; — About Watch; — desktop/mobile layout; — long names, references, and missing data. It is necessary to maintain current functionality and existing API contracts. 7. Header and Footer — unified style across all pages; — responsive navigation; — mobile menu; — correct active/hover/focus states; — absence of discrepancies between the homepage, catalog, and PDP. 8. Interface states For dynamic blocks, check: — loading; — empty data; — API error; — insufficient data; — missing image; — missing price; — long text; — mobile display. There is no need to develop new complex business logic. It is necessary to correctly visualize already existing states. 9. Quality and performance — do not worsen SEO and current indexing; — maintain correct metadata and semantic HTML; — avoid critical layout shifts; — optimize images and fonts; — consider reduced motion for animations; — check basic accessibility: focus states, contrast, keyboard navigation; — do not include heavy libraries without justified necessity. 10. Staging and QA — deploy changes on staging; — check main types of pages; — check desktop, tablet, and mobile; — fix visual and responsive bugs; — after acceptance, perform production deployment; — ensure bug fixes for the implemented scope for at least 7 calendar days after deployment. RESULT OF WORK — Pull Request with frontend code; — implemented new homepage; — responsive desktop/tablet/mobile; — unified fonts, cards, and basic UI components; — visually agreed catalog, PDP, and informational pages; — staging deployment; — fixing identified visual errors; — production deployment; — brief description of modified components; — 7-day bug-fix period after acceptance. ACCEPTANCE CRITERIA 1. The homepage matches the provided design. 2. All sections work correctly on desktop, tablet, and mobile. 3. Header and footer are uniform across all pages. 4. Catalog and PDP visually correspond to the new system. 5. Current functionality of the site is not disrupted. 6. API contracts and backend logic are not changed without agreement. 7. No horizontal scrolling and critical layout shifts. 8. Fonts and images load correctly. 9. Loading, empty, and error states are displayed without breaking the layout. 10. Changes are checked on staging and deployed to production. 11. Visual errors identified during acceptance are fixed within the agreed scope. WHAT IS NOT REQUIRED — backend development; — changes to business logic; — creation of a new catalog or CMS; — development of a new API; — complete redesign of each informational page; — new user features not present in the layouts; — development of a complex design system from scratch; — creation of a new project instead of improving the existing one; — changes to the SEO structure without separate agreement. REQUIREMENTS FOR THE PERFORMER — confident in Next.js / React / TypeScript; — experience working with existing production projects; — quality responsive layout; — experience implementing designs from Figma; — component approach; — confident working with CSS / CSS Modules / Tailwind or the existing project system; — understanding of Core Web Vitals; — Git / Pull Request workflow; — ability to work through staging. IN RESPONSE, IT IS MANDATORY TO INDICATE 1. Fixed price for the full mandatory scope. 2. Completion time in working days. 3. Estimate in hours. 4. When you are ready to start. 5. Links to 2–3 relevant projects on Next.js/React. 6. Experience working with catalogs, product cards, or analytical interfaces. 7. What will be needed for an accurate estimate before starting work. 8. Does the price include: — staging; — responsive QA; — production deployment; — bug fixes; — 7-day bug-fix period. Template responses without reviewing the requirements and without a specific estimate will not be considered. Access to production is not provided at the first stage. Work begins after a limited code review and is deployed through staging.

There is an active production platform with a catalog and automatic updates of external offers and prices. Stack: — Node.js / TypeScript; — PostgreSQL; — existing price refresh service and cron; — separate ready Python module for validation and selection of offers; — staging and production. It is necessary to make targeted improvements to the existing price refresh pipeline without completely rewriting the backend. MANDATORY SCOPE 1. Integration of the Python module — The Python module remains a separate component; — returns a structured result: offers, selected offer, statuses, and risk flags; — Node.js validates the result and performs a write to the database; — provide for error handling and partial/failed runs; — the legacy pipeline is not turned off until QA is completed. 2. Launch refresh by list Add launch: — by one slug/id; — by the provided list of slug/id. Assume CLI or existing service API. A new user interface is not required. 3. Shadow Mode New results must be recorded separately and not affect production until QA. Shadow fields required: — price; — selected offer ID; — direct URL; — offer status; — risk/QA flags; — checkedAt; — engineVersion. 4. Expanding the existing offers table Add: — source; — external_offer_id; — last_seen_at; — last_checked_at; — engine_version; — risk flags or storage in existing JSON; — unique constraint to protect against duplicates. It is not required to create a new parallel offer system if the existing table can be safely expanded. 5. UPSERT, STALE, and DB transaction Replace the current DELETE → CREATE scheme: — UPSERT existing and new offers; — offers missing in the full successful snapshot are translated to STALE; — in case of API error, partial result, or incomplete snapshot, active offers should not become STALE; — updating offers, selected offer metadata, and shadow fields for one model is performed within one DB transaction; — in case of an error, a full rollback is performed. 6. Canonical-safe refresh Price refresh should not change: — brand; — reference; — model; — collection; — name/title; — slug; — descriptions; — images; — SEO fields. Only offer, price, and shadow data are updated. 7. Preserving current cron logic Preserve: — existing cron; — rolling batches; — cooldown; — checking PRICE_REFRESH_MIN_DAYS before calling the external API; — legacy production pipeline until Shadow QA is completed. 8. Audit output One option is sufficient: — shadow columns in the existing admin table; or — CSV export. Minimum data: — model/reference; — production price; — shadow price; — delta; — production/shadow URL; — status; — risk flags; — checkedAt; — engineVersion. A new complex dashboard is not required. 9. Staging and QA — DB migrations; — staging deployment; — smoke test on 5 provided models; — then Shadow Mode on approximately 50 models; — fixing technical errors identified during these runs; — brief documentation of the Python → Node.js contract and rollback procedure. OPTIONALLY ASSESS SEPARATELY Simple technical promotion without a new UI: — promotion of one model by slug; — promotion of a list of slugs; — transferring confirmed shadow values to production; — technical check after rollout. RESULT — Pull Request; — DB migrations; — working integration Python → Node.js; — Shadow Mode; — UPSERT, STALE, and transactional update; — launch by slug/id; — staging deployment; — smoke-test results; — brief documentation; — at least 7 days of bug fixes for the implemented scope after acceptance. IN RESPONSE, INDICATE 1. Fixed price for the mandatory scope. 2. Separate cost for the promotion mechanism. 3. Timeline. 4. Hourly estimate. 5. When you are ready to start. 6. Experience with PostgreSQL transactions, migrations, and ingestion pipelines. 7. What questions need to be clarified before starting. 8. Whether staging, QA, migrations, and bug-fix period are included. Template responses without specific estimates will not be considered. Access to production is not provided at the first stage. Work begins with limited code review and staging.

Good day, 1) update jQuery** to the latest version (3.x) with jQuery Migrate included 2) Thoroughly test the functionality of the application 3) and fix any possible errors so that all scripts are compatible with each other by versions here it is necessary to completely rewrite https://filtry.in.ua/assets/libs/libs.js for the new version of jQuery since it has an old Bootstrap and many custom functions written

Description: It is necessary to create a JavaScript script for the Tampermonkey extension. The script will work in an internal CRM system.Logic of operation: The script must read the unique text ID of the current active dialogue on the page (there are a total of 5–10 different IDs). Depending on the ID, the script takes the corresponding text instruction (System Prompt) from the settings. The mapping of parameters by ID should be moved to a separate convenient settings window for the script. When a new message appears in the chat window, the script sends this text along with the prompt via the OpenAI API (model gpt-4o-mini). The received response is inserted into the text input field and initiates sending with a random delay of 20–45 seconds to simulate the natural operation of the operator.Work is purely with text. Budget — 6000 UAH. I am waiting for proposals from developers with experience in working with the OpenAI API and writing browser automation scripts.