[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"media-detail-with-another-proektirovanie-ii-poiska":3},{"media":4,"anotherMedia":72},{"id":5,"documentId":6,"title":7,"date":8,"description":9,"order":10,"slug":11,"showOnMainPage":12,"createdAt":13,"updatedAt":14,"publishedAt":15,"locale":16,"media_areas":17,"cover":18,"content":67},401,"w0y206w0w1sb2u005skdj3pa","Как проектировать проверяемый ИИ-поиск: источники, логи и аудит\n","2026-09-10",null,1,"proektirovanie-ii-poiska",true,"2026-09-10T14:09:42.411Z","2026-09-23T12:16:22.415Z","2026-09-23T12:16:22.469Z","ru",[],{"id":19,"documentId":20,"name":21,"alternativeText":9,"caption":9,"width":22,"height":23,"formats":24,"hash":59,"ext":26,"mime":29,"size":60,"url":61,"previewUrl":9,"provider":62,"provider_metadata":9,"createdAt":63,"updatedAt":63,"publishedAt":63,"related":64},723,"w3k42ovrywwevzxh1288ctpw","photo_2026-09-10 16.04.45.jpeg",1920,1080,{"large":25,"small":35,"medium":43,"thumbnail":51},{"ext":26,"url":27,"hash":28,"mime":29,"name":30,"path":9,"size":31,"width":32,"height":33,"sizeInBytes":34},".jpeg","https:\u002F\u002Fstrapi.qtim.pro\u002Fuploads\u002Flarge_photo_2026_09_10_16_04_45_8bad297a5f.jpeg","large_photo_2026_09_10_16_04_45_8bad297a5f","image\u002Fjpeg","large_photo_2026-09-10 16.04.45.jpeg",85.42,1000,563,85424,{"ext":26,"url":36,"hash":37,"mime":29,"name":38,"path":9,"size":39,"width":40,"height":41,"sizeInBytes":42},"https:\u002F\u002Fstrapi.qtim.pro\u002Fuploads\u002Fsmall_photo_2026_09_10_16_04_45_8bad297a5f.jpeg","small_photo_2026_09_10_16_04_45_8bad297a5f","small_photo_2026-09-10 16.04.45.jpeg",29.13,500,281,29130,{"ext":26,"url":44,"hash":45,"mime":29,"name":46,"path":9,"size":47,"width":48,"height":49,"sizeInBytes":50},"https:\u002F\u002Fstrapi.qtim.pro\u002Fuploads\u002Fmedium_photo_2026_09_10_16_04_45_8bad297a5f.jpeg","medium_photo_2026_09_10_16_04_45_8bad297a5f","medium_photo_2026-09-10 16.04.45.jpeg",55.37,750,422,55368,{"ext":26,"url":52,"hash":53,"mime":29,"name":54,"path":9,"size":55,"width":56,"height":57,"sizeInBytes":58},"https:\u002F\u002Fstrapi.qtim.pro\u002Fuploads\u002Fthumbnail_photo_2026_09_10_16_04_45_8bad297a5f.jpeg","thumbnail_photo_2026_09_10_16_04_45_8bad297a5f","thumbnail_photo_2026-09-10 16.04.45.jpeg",9.58,245,138,9583,"photo_2026_09_10_16_04_45_8bad297a5f",199.29,"https:\u002F\u002Fstrapi.qtim.pro\u002Fuploads\u002Fphoto_2026_09_10_16_04_45_8bad297a5f.jpeg","aws-s3","2026-09-10T14:09:39.285Z",[65],{"__type":66,"id":5,"documentId":6,"title":7,"date":8,"description":9,"order":10,"slug":11,"showOnMainPage":12,"createdAt":13,"updatedAt":14,"publishedAt":15,"locale":16},"api::media.media",[68],{"__component":69,"id":70,"text":71},"media.text",364,"\u003Cp class=\"p1\">Пользователь просит ChatGPT найти свежие правила для онлайн-платформ. Сервис обращается к вебу, выбирает источники, собирает ответ и показывает ссылки. На экране — чат-бот. Внутри — информационный поиск.\u003C\u002Fp>\u003Cp class=\"p1\">31 августа 2026 года Еврокомиссия признала ChatGPT очень крупной онлайн-поисковой системой по DSA. Поводом стала функция веб-поиска: ChatGPT сам выбирает источники и собирает из них ответ.\u003C\u002Fp>\u003Cp class=\"p1\">Мы проектируем ИИ-поиск и RAG-системы. В одном из наших проектов мы сделали RAG-консультанта для магазина дверей. Он работал только с каталогом: уточнял размеры и требования, подбирал товары и объяснял выбор. Сложные запросы передавал менеджеру вместе с собранным контекстом. Этот кейс показывает, какой контроль нужен даже закрытой системе — и что меняется, когда к ней добавляют поиск в интернете.\u003C\u002Fp>\u003Ch2>\u003Cstrong>Один ответ скрывает четыре решения внутри продукта\u003C\u002Fstrong>\u003C\u002Fh2>\u003Cp class=\"p1\">Обычный поисковик показывает выдачу: человек сам открывает страницы и сравнивает информацию. ИИ-поиск проходит этот путь внутри продукта и отдаёт готовый текст со ссылками.\u003C\u002Fp>\u003Cp class=\"p1\">У этой цепочки как минимум четыре слоя:\u003C\u002Fp>\u003Cul>\u003Cli data-list-item-id=\"e3af33d4370ed1ebf12bedac0a3e9db5f\">\u003Cp class=\"p1\">система интерпретирует вопрос и решает, нужен ли поиск в интернете;\u003C\u002Fp>\u003C\u002Fli>\u003Cli data-list-item-id=\"e009b12b8ae3d6e0a50cbe3508101b836\">\u003Cp class=\"p1\">поисковый контур формирует запросы и отбирает документы;\u003C\u002Fp>\u003C\u002Fli>\u003Cli data-list-item-id=\"ee5ef823f875d006955804ae2ab40fcd1\">\u003Cp class=\"p1\">модель выбирает фрагменты, разрешает противоречия и собирает ответ;\u003C\u002Fp>\u003C\u002Fli>\u003Cli data-list-item-id=\"e04ba32cacd95b2215b300770072bcc9f\">\u003Cp class=\"p1\">фильтры, правила продукта и персонализация меняют то, что увидит пользователь.\u003C\u002Fp>\u003C\u002Fli>\u003C\u002Ful>\u003Cp class=\"p1\">ИИ-поиск нужно проверять как поисковую систему: от вопроса до источников и ответа. Финальный текст не показывает, какие запросы, источники и фильтры к нему привели. Одинаковый ответ может получиться из разных цепочек, а одна версия системы — отвечать по-разному после обновления выдачи.\u003C\u002Fp>\u003Ch2>\u003Cstrong>Проверяемость закладывают до релиза\u003C\u002Fstrong>\u003C\u002Fh2>\u003Cp class=\"p1\">DSA требует от крупнейших сервисов оценивать системные риски, проходить аудит и обеспечивать надзор. Для ChatGPT требования начнут действовать в январе 2027 года. Значит, журналы событий, версии компонентов и источники нужно связывать до релиза: восстановить ход ответа задним числом не получится.\u003C\u002Fp>\u003Cp class=\"p1\">Решение касается ChatGPT и не переносит обязанности DSA на все ИИ-продукты. Сам регламент применяется к посредническим сервисам, которые предлагаются пользователям в ЕС, независимо от страны провайдера.\u003C\u002Fp>\u003Cp class=\"p1\">Проверяемость нужна и за пределами ЕС. Когда сервис сам выбирает источники и собирает ответ, команда должна уметь восстановить ход решения, заметить вредный результат и остановить функцию без потери данных. Требования зависят от широты источников, размера аудитории и последствий ответа. Конкретные уровни разберём после базовых требований к релизу.\u003C\u002Fp>\u003Ch2>\u003Cstrong>Аудит начинается до релиза крупной функции\u003C\u002Fstrong>\u003Cbr> \u003C\u002Fh2>\u003Cp class=\"p1\">Статья 34 DSA требует оценивать системные риски минимум раз в год и перед запуском функций, которые, вероятно, окажут критическое влияние на выявленные риски. Для продуктовой команды это похоже на новый тип релизного шлюза.\u003C\u002Fp>\u003Cp class=\"p1\">Перед крупной функцией нужно связать четыре объекта:\u003C\u002Fp>\u003Cp class=\"p1\">сценарий пользователя и группы, которых он затрагивает;\u003C\u002Fp>\u003Cp class=\"p1\">риск и измеримый сигнал, по которому его можно заметить;\u003C\u002Fp>\u003Cp class=\"p1\">меру снижения риска: ограничение, дополнительную проверку, изменение интерфейса или правил;\u003C\u002Fp>\u003Cp class=\"p1\">план выпуска: тестовую группу, мониторинг, условие остановки и откат.\u003C\u002Fp>\u003Cp class=\"p1\">DSA не задаёт схему данных и набор инструментов. Мы предлагаем связать риск, релиз и события одной функцией. Иначе оценка остаётся в документе, релиз — в трекере, события — в разных журналах; при проверке связь между ними приходится восстанавливать заново.\u003C\u002Fp>\u003Cp class=\"p1\">Карточка риска должна ссылаться на версию релиза, метрика — на панель мониторинга, решение о запуске — на ответственного человека или роль. Функциональный флаг и сценарий отката надёжнее обещания «быстро выключим»: оно не исполняется через API.\u003C\u002Fp>\u003Ch2>\u003Cstrong>Финальный текст не объяснит, почему система ответила именно так\u003C\u002Fstrong>\u003C\u002Fh2>\u003Cp class=\"p1\">По одному экрану нельзя воспроизвести ответ языковой модели. На него влияют версия модели, системная инструкция, доступные инструменты, поисковые запросы, найденные документы, фильтры и состояние внешних источников.\u003C\u002Fp>\u003Cp class=\"p1\">Для расследования нужен общий идентификатор запроса. Он связывает последовательность событий:\u003C\u002Fp>\u003Cul>\u003Cli data-list-item-id=\"e8f59001849b6f37e5c1d02fd7802907e\">\u003Cp class=\"p1\">какая версия модели и инструкции работала;\u003C\u002Fp>\u003C\u002Fli>\u003Cli data-list-item-id=\"e73dabbfdc7877b3e83e9ed670e5ab7a2\">\u003Cp class=\"p1\">почему система запустила поиск или другой инструмент;\u003C\u002Fp>\u003C\u002Fli>\u003Cli data-list-item-id=\"e7299b7b17bac10fa2fa182da783ca7e2\">\u003Cp class=\"p1\">какие запросы отправила и какие источники получила;\u003C\u002Fp>\u003C\u002Fli>\u003Cli data-list-item-id=\"e0683f9245934cc3ad694cfc27c2b516d\">\u003Cp class=\"p1\">какие политики и фильтры сработали;\u003C\u002Fp>\u003C\u002Fli>\u003Cli data-list-item-id=\"e0c4230ae269c5123d9421b0e7b86c598\">\u003Cp class=\"p1\">какой ответ увидел пользователь и какие ссылки были показаны;\u003C\u002Fp>\u003C\u002Fli>\u003Cli data-list-item-id=\"efe1b9dc8e04c09512983e2ba8830a4e9\">\u003Cp class=\"p1\">было ли вмешательство человека, повторный запуск или откат.\u003C\u002Fp>\u003C\u002Fli>\u003C\u002Ful>\u003Cp class=\"p1\">Журнал не должен превращаться в копию диалога. Срок хранения, доступ, маскирование и удаление нужно определить вместе с трассировкой. Чем подробнее запись, тем выше её ценность и риск утечки. Цель — восстановить решение, не хранить всё содержимое диалога.\u003C\u002Fp>\u003Ch2>\u003Cstrong>Доступ к данным нельзя достроить за выходные\u003C\u002Fstrong>\u003C\u002Fh2>\u003Cp class=\"p1\">Для крупнейших платформ DSA требует отдельного контура доступа к данным для надзора и исследований.\u003C\u002Fp>\u003Cp class=\"p1\">Прямой доступ исследователя к рабочей базе угрожает приватности, коммерческой тайне и стабильности сервиса. Выгрузки «по запросу» тоже ненадёжны: поля меняются, методика неизвестна, одинаковые показатели считают по-разному.\u003C\u002Fp>\u003Cp class=\"p1\">Нужны версия схемы, словарь показателей, правила обезличивания, журнал обращений и воспроизводимая выборка. Контур должен отделять данные для проверки риска от информации, раскрытие которой создаст новый риск.\u003C\u002Fp>\u003Cp class=\"p1\">Такой контур редко создают за один спринт: его сложность зависит от истории данных в сервисе.\u003C\u002Fp>\u003Ch2>\u003Cstrong>Проверяемость замедляет эксперимент\u003C\u002Fstrong>\u003C\u002Fh2>\u003Cp class=\"p1\">Проверяемость требует ресурсов. Карточки рисков, проверочные сценарии, версии инструкций, расширенные журналы и контролируемые выгрузки добавляют работу до релиза. Хранение событий требует инфраструктуры и правил доступа.\u003C\u002Fp>\u003Cp class=\"p1\">Избыточный контроль тоже обходится дорого. Небольшому внутреннему помощнику по документам одного отдела не нужен контур уровня глобального поисковика. Объём контроля растёт вместе с широтой источников, размером аудитории и последствиями ответа.\u003C\u002Fp>\u003Cp class=\"p1\">Это шкала из четырёх уровней контроля: от личного контекста пользователя до крупных публичных систем. Каждый следующий уровень расширяет источники данных или повышает цену ошибки.\u003C\u002Fp>\u003Cp class=\"p1\">Контекст пользователя. Система работает только с тем, что человек передал в запрос. Нужны версия модели, базовый журнал ошибок и понятная граница хранения данных.\u003C\u002Fp>\u003Cp class=\"p1\">Закрытая база знаний. Появляются идентификаторы документов, контроль прав, ссылки на источники, тесты качества поиска и возможность удалить устаревший материал из индекса.\u003C\u002Fp>\u003Cp class=\"p1\">Открытый веб и публичная аудитория. Добавляются история поисковых запросов, состав источников, контроль разнообразия выдачи, сценарии вредных ответов, поэтапный выпуск и быстрый откат.\u003C\u002Fp>\u003Cp class=\"p1\">Большой масштаб или чувствительные последствия. Нужны формализованная оценка рисков, независимая проверка, воспроизводимые отчёты и отдельный контур доступа к данным.\u003C\u002Fp>\u003Cp class=\"p1\">Например, наш консультант для магазина дверей относится ко второму уровню — закрытой базе знаний.\u003C\u002Fp>\u003Ch2>\u003Cstrong>Пять вопросов перед новым релизом\u003C\u002Fstrong>\u003C\u002Fh2>\u003Cp class=\"p1\">Перед выпуском ИИ-функции мы задаём команде пять вопросов:\u003C\u002Fp>\u003Cul>\u003Cli data-list-item-id=\"ed09ca978a29b7f02c1df0a1d4d38cbac\">\u003Cp class=\"p1\">в каком информационном контуре работает система: запрос пользователя, корпоративные документы, партнёрские источники или открытый веб;\u003C\u002Fp>\u003C\u002Fli>\u003Cli data-list-item-id=\"ead2474062272738d11070da3cfccfa65\">\u003Cp class=\"p1\">на каком этапе продукт выбирает источники и может сузить картину для пользователя;\u003C\u002Fp>\u003C\u002Fli>\u003Cli data-list-item-id=\"e024a35accf0f882a6098ead1685f5cb2\">\u003Cp class=\"p1\">можно ли восстановить цепочку от запроса до ответа с версиями модели, инструкций и правил;\u003C\u002Fp>\u003C\u002Fli>\u003Cli data-list-item-id=\"e6276ea5df6c09df4ef6b4c2f6bc25fd1\">\u003Cp class=\"p1\">какие группы пользователей и виды вреда затрагивает функция, а по какому сигналу команда заметит проблему;\u003C\u002Fp>\u003C\u002Fli>\u003Cli data-list-item-id=\"e6ed3f29120a682f8c042a8b6356c07a0\">\u003Cp class=\"p1\">кто сможет проверить решение через месяц и какие данные ему будут доступны.\u003C\u002Fp>\u003C\u002Fli>\u003C\u002Ful>\u003Cp class=\"p1\">Эти ответы показывают объём продукта. Закрытой базе достаточно идентификаторов источников и версионирования. Открытый веб потребует журнала решений, контура проверок и плана остановки функции.\u003C\u002Fp>\u003Ch2>\u003Cstrong>Пользователь видит диалог. Команда должна видеть цепочку решений\u003C\u002Fstrong>\u003C\u002Fh2>\u003Cp class=\"p1\">Наше правило: когда ИИ выбирает источники и собирает ответ, поиск и генерацию нужно проектировать как одну проверяемую цепочку.\u003C\u002Fp>\u003Cp class=\"p1\">Мы разрабатываем ИИ-чатботы, RAG-системы и интеграции языковых моделей. На разборе ИИ-проекта можем определить уровень контроля, который нужен вашему сценарию, и заложить его в архитектуру до масштабирования.\u003C\u002Fp>",[73,138,194],{"createdAt":74,"id":41,"documentId":75,"title":76,"date":77,"description":9,"order":40,"slug":78,"showOnMainPage":12,"updatedAt":74,"publishedAt":79,"locale":16,"cover":80,"content":118,"media_event":9,"media_areas":122,"seo":9,"localizations":137},"2026-09-11T14:21:51.168Z","ggdl1zmuuohkn3ubgxqu5wdz","Этапы разработки сайта: 7 контрольных точек от идеи до запуска","2026-09-11","etapy-razrabotki-sayta-ot-idei-do-zapuska","2026-09-11T14:21:51.261Z",{"id":81,"documentId":82,"name":83,"alternativeText":9,"caption":9,"width":84,"height":85,"formats":86,"hash":113,"ext":88,"mime":91,"size":114,"url":115,"previewUrl":9,"provider":62,"provider_metadata":9,"createdAt":116,"updatedAt":116,"publishedAt":117},729,"l068mj742a03d0sck2tkbr0r","Изображение Codex 11 сент. 2026 г., 16_54_52.png",1672,941,{"large":87,"small":95,"medium":101,"thumbnail":107},{"ext":88,"url":89,"hash":90,"mime":91,"name":92,"path":9,"size":93,"width":32,"height":33,"sizeInBytes":94},".png","https:\u002F\u002Fstrapi.qtim.pro\u002Fuploads\u002Flarge_Izobrazhenie_Codex_11_sent_2026_g_16_54_52_ca0cfe709e.png","large_Izobrazhenie_Codex_11_sent_2026_g_16_54_52_ca0cfe709e","image\u002Fpng","large_Изображение Codex 11 сент. 2026 г., 16_54_52.png",547.17,547174,{"ext":88,"url":96,"hash":97,"mime":91,"name":98,"path":9,"size":99,"width":40,"height":41,"sizeInBytes":100},"https:\u002F\u002Fstrapi.qtim.pro\u002Fuploads\u002Fsmall_Izobrazhenie_Codex_11_sent_2026_g_16_54_52_ca0cfe709e.png","small_Izobrazhenie_Codex_11_sent_2026_g_16_54_52_ca0cfe709e","small_Изображение Codex 11 сент. 2026 г., 16_54_52.png",145.2,145200,{"ext":88,"url":102,"hash":103,"mime":91,"name":104,"path":9,"size":105,"width":48,"height":49,"sizeInBytes":106},"https:\u002F\u002Fstrapi.qtim.pro\u002Fuploads\u002Fmedium_Izobrazhenie_Codex_11_sent_2026_g_16_54_52_ca0cfe709e.png","medium_Izobrazhenie_Codex_11_sent_2026_g_16_54_52_ca0cfe709e","medium_Изображение Codex 11 сент. 2026 г., 16_54_52.png",316.17,316171,{"ext":88,"url":108,"hash":109,"mime":91,"name":110,"path":9,"size":111,"width":56,"height":57,"sizeInBytes":112},"https:\u002F\u002Fstrapi.qtim.pro\u002Fuploads\u002Fthumbnail_Izobrazhenie_Codex_11_sent_2026_g_16_54_52_ca0cfe709e.png","thumbnail_Izobrazhenie_Codex_11_sent_2026_g_16_54_52_ca0cfe709e","thumbnail_Изображение Codex 11 сент. 2026 г., 16_54_52.png",39.19,39189,"Izobrazhenie_Codex_11_sent_2026_g_16_54_52_ca0cfe709e",467.8,"https:\u002F\u002Fstrapi.qtim.pro\u002Fuploads\u002FIzobrazhenie_Codex_11_sent_2026_g_16_54_52_ca0cfe709e.png","2026-09-11T13:56:10.406Z","2026-09-11T13:56:10.407Z",[119],{"__component":69,"id":120,"text":121},243,"\u003Cp>Дата запуска уже стоит в календаре. Дизайн почти согласован, руководитель ждёт новую версию сайта к конференции, а на рабочем созвоне выясняется: тексты ещё собирают, формы не связаны с CRM, старые адреса страниц никто не зафиксировал.\u003Cbr>\u003Cbr>Проект теряет время в стыках между решениями, даже когда код не вызывает сложностей. Сайт проходит через аналитику, структуру, контент, дизайн, разработку, тестирование и релиз. Пропуск одного звена возвращает команду на несколько шагов назад.\u003Cbr>Разберём этапы разработки сайта по порядку, результат каждого шага и условия перехода дальше. Эта схема подходит для корпоративных сайтов, сервисных страниц и других веб-проектов. Масштаб работ меняется, логика процесса сохраняется.\u003C\u002Fp>\u003Ch2>1. Цель сайта задаёт границы проекта до первой оценки\u003C\u002Fh2>\u003Cp>Фраза «нужен современный сайт» не помогает выбрать ни структуру, ни технологию. Сначала команда формулирует бизнес-задачу: получать квалифицированные заявки, объяснять сложный продукт, поддерживать продажи, нанимать специалистов, выводить компанию на новый рынок или разгружать сотрудников от повторяющихся операций.\u003Cbr>\u003Cbr>Одна главная цель задаёт приоритеты. Для лидогенерации важны сценарии заявки и связь с CRM. Для корпоративного ресурса с большим объёмом контента — управление страницами, поиск, роли редакторов и SEO. Для кабинета клиента на первый план выходят авторизация, права доступа, данные и интеграции.\u003Cbr>\u003Cbr>На этом этапе фиксируют аудитории, ключевые действия, ограничения, владельца продукта и критерии успеха. Результат помещается в короткий паспорт проекта: зачем создаём сайт, для кого, какое действие считаем целевым, что входит в первую версию и кто принимает решения.\u003C\u002Fp>\u003Ch2>2. Discovery превращает идею в карту страниц и систем\u003C\u002Fh2>\u003Cp>Discovery — короткий этап исследования перед проектированием. Команда проводит интервью со стейкхолдерами, изучает текущую аналитику и обращения клиентов, разбирает контент, сравнивает конкурентов и описывает путь пользователя. Здесь же появляется список внешних систем: CRM, ERP, ATS, платёжные сервисы, склад, рассылки, аналитика.\u003Cbr>\u003Cbr>Простой лендинг не требует многонедельного исследования. Его discovery может уместиться в одну рабочую сессию и проверку материалов. Отказываться от этапа целиком рискованно: тогда вопросы об аудитории, содержании и заявках всё равно возникнут, только уже на макетах или в коде.\u003Cbr>\u003Cbr>На странице разработки корпоративных сайтов мы показываем \u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fqtim.pro\u002Fservices\u002Fcorporate\">базовый маршрут на восемь недель\u003C\u002Fa>: две недели на discovery, две–три на дизайн и контент, две–три на разработку и интеграции, ещё одну на запуск и SEO-перенос. Это ориентир для понятного корпоративного контура. Портал, интернет-магазин или сервис с личными кабинетами потребует другого календаря.\u003Cbr>\u003Cbr>Выход discovery — согласованные требования, карта страниц, перечень интеграций, границы первой версии и оценка. После этого смета опирается на состав работ вместо предварительного числа экранов.\u003C\u002Fp>\u003Ch2>3. Прототип находит дорогие ошибки до дизайна\u003C\u002Fh2>\u003Cp>Черновой каркас показывает логику страниц без финальной графики. На нём видно, где пользователь узнаёт главное, как переходит к услуге, что заполняет в форме и какой ответ получает после отправки. Для сложного продукта отдельно прорисовывают роли, состояния, ошибки и переходы между системами.\u003Cbr>\u003Cbr>Параллельно собирают контент. Это важная часть проектирования: реальный заголовок может занять две строки, таблица тарифов потребует больше места, а кейс без подтверждённых цифр нельзя строить вокруг результата. Макеты с условным текстом скрывают такие конфликты до самой дорогой стадии.\u003Cbr>\u003Cbr>Результат этапа — кликабельный прототип ключевых сценариев и контентная карта. Их проверяют владелец продукта, маркетинг, продажи и сотрудники, которые будут обновлять сайт. В разработку передают уже согласованный маршрут пользователя.\u003C\u002Fp>\u003Ch2>4. Дизайн-система удерживает десятки страниц в одном ритме\u003C\u002Fh2>\u003Cp>После проверки структуры задают визуальное направление, собирают компоненты и состояния: кнопки, формы, карточки, таблицы, меню, уведомления, ошибки, мобильные версии. Из этих элементов складывается дизайн-система, которую можно развивать вместе с сайтом.\u003Cbr>\u003Cbr>На макетах проверяют контраст, размер текста, управление с клавиатуры, фокус элементов и понятность ошибок. \u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fwww.w3.org\u002FTR\u002FWCAG22\u002F\">W3C\u003C\u002Fa> рекомендует использовать WCAG 2.2 как актуальную цель для веб-доступности. Эти требования дешевле заложить в компоненты, чем исправлять отдельно на каждой странице перед релизом.\u003Cbr>\u003Cbr>Готовый дизайн охватывает комплект состояний каждого компонента. Одного привлекательного главного экрана недостаточно. У формы есть успешная отправка, ошибка и загрузка. У меню — мобильная версия. У карточки — длинный заголовок и отсутствие изображения. Такой макет даёт разработчикам правила вместо коллекции идеальных картинок.\u003C\u002Fp>\u003Ch2>5. Разработка начинается с архитектуры, CMS и среды проверки\u003C\u002Fh2>\u003Cp>До вёрстки команда выбирает архитектуру и способ управления контентом. Небольшому сайту может хватить конструктора или готовой CMS. Корпоративному ресурсу с мультиязычностью, интеграциями и частыми кампаниями часто нужна отдельная система управления контентом и компонентный интерфейс. Решение зависит от задач, нагрузки, команды поддержки и планов развития.\u003Cbr>\u003Cbr>Дальше frontend превращает компоненты в работающий интерфейс, backend обрабатывает данные и интеграции, CMS даёт редакторам контроль над страницами. Разработка идёт в отдельной тестовой среде. Там маркетинг наполняет разделы, а заказчик проверяет сценарии без риска изменить действующий сайт.\u003Cbr>\u003Cbr>На этом же этапе подключают аналитику. Список событий составляют заранее: отправка формы, скачивание материала, переход к контакту, поиск, ошибка оплаты или другой целевой шаг. После релиза команда должна видеть весь путь пользователя; общего числа посещений для этого мало.\u003C\u002Fp>\u003Ch2>6. Проверка сайта выходит за пределы кнопки «Отправить»\u003C\u002Fh2>\u003Cp>Функциональное тестирование отвечает на базовый вопрос: сценарий работает во всех заявленных состояниях? Затем добавляются проверки на разных браузерах и экранах, редактура контента, SEO-аудит, доступность, производительность и безопасность.\u003Cbr>\u003Cbr>\u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fdevelopers.google.com\u002Fsearch\u002Fdocs\u002Ffundamentals\u002Fget-started-developers\">Google\u003C\u002Fa> советует ещё при разработке делать сайт безопасным, быстрым, доступным и удобным на разных устройствах. Для поисковой видимости также важны семантический HTML, уникальные заголовки и описания страниц, доступный в DOM текст. Эти пункты входят в требования и критерии приёмки вместо памятки на день релиза.\u003Cbr>\u003Cbr>Производительность проверяют на ключевых шаблонах и реальных устройствах. По данным \u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Falmanac.httparchive.org\u002Fen\u002F2025\u002Fperformance\">Web Almanac\u003C\u002Fa> за 2025 год, хорошие Core Web Vitals были у 48% мобильных и 56% десктопных сайтов в исследуемой выборке. Даже зрелый рынок регулярно не проходит базовую проверку скорости, отзывчивости и визуальной стабильности.\u003Cbr>\u003Cbr>Для сайта с авторизацией, формами, кабинетами или платежами нужен отдельный контур безопасности. \u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fowasp.org\u002FTop10\u002F2025\u002F0x00_2025-Introduction\u002F\">OWASP Top 10:2025\u003C\u002Fa> помогает расставить приоритеты: контроль доступа, конфигурация, зависимости, защита данных, обработка ошибок и журналирование. Этот список не заменяет модель угроз, но не даёт свести проверку к сертификату HTTPS.\u003C\u002Fp>\u003Ch2>7. Релиз связывает домен, редиректы, аналитику и план отката\u003C\u002Fh2>\u003Cp>Перед запуском команда составляет сценарий релиза. В нём есть домен и сертификат, резервная копия, перенос контента, настройки аналитики, формы и уведомления, карта 301-редиректов, sitemap, robots.txt, доступы, мониторинг и ответственные. Для критичных систем добавляют план отката: что возвращаем, кто принимает решение и сколько времени допустим простой.\u003Cbr>\u003Cbr>После публикации проверяют сайт уже в боевой среде: открываются ли страницы без авторизации, доходят ли заявки, сохраняются ли рекламные параметры, видит ли поисковый робот контент, нет ли ошибок в логах. \u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fdevelopers.google.com\u002Fsearch\u002Fdocs\u002Ffundamentals\u002Fget-on-google\">Google рекомендует\u003C\u002Fa> отправить sitemap и следить за индексацией через Search Console.\u003Cbr>\u003Cbr>Релиз закрывает проектную фазу. Дальше начинается развитие сайта. Первые недели показывают реальные поисковые запросы, устройства, скорость, ошибки и поведение посетителей. Команда собирает эти сигналы в план развития и отделяет срочные дефекты от новых гипотез.\u003C\u002Fp>\u003Ch2>\u003Cbr>Контрольная карта: что должно быть готово на каждом этапе\u003C\u002Fh2>\u003Col>\u003Cli data-list-item-id=\"ed51edf7af72fcf1225e5437576c1a3b3\">Цель и рамки: паспорт проекта, аудитории, целевое действие, границы первой версии и владелец решения.\u003C\u002Fli>\u003Cli data-list-item-id=\"e52337544b359295ff45f989e61c4ff6f\">Discovery: требования, карта страниц, интеграции, риски, оценка и календарный план.\u003C\u002Fli>\u003Cli data-list-item-id=\"ea8813c8d71bf242ad4f95d7768c90ebd\">Прототип и контент: проверенные сценарии, структура ключевых страниц и список материалов.\u003C\u002Fli>\u003Cli data-list-item-id=\"e837627758ec072596926fc899fc3318d\">Дизайн: компоненты, адаптивные макеты, состояния интерфейса и правила доступности.\u003C\u002Fli>\u003Cli data-list-item-id=\"e86e6792e5be6cd8b072f1ed2aa0cd767\">Разработка: работающий сайт в тестовой среде, CMS, интеграции и события аналитики.\u003C\u002Fli>\u003Cli data-list-item-id=\"e947f2f47c918dee2debaba52d08c4b9a\">Тестирование: закрытые критичные дефекты и подтверждённые критерии приёмки.\u003C\u002Fli>\u003Cli data-list-item-id=\"e7ab4da0de31cb7940a8de302e6a45f2f\">Запуск: домен, редиректы, аналитика, мониторинг, резервная копия, план отката и список задач после релиза.\u003C\u002Fli>\u003C\u002Fol>\u003Cp>Эта карта помогает заметить разрыв заранее. Дизайн не уходит в разработку без реального контента и состояний. Релиз не назначают до проверки редиректов и аналитики. Новый этап начинается после приёмки результата предыдущего.\u003C\u002Fp>\u003Ch2>Семь этапов держатся на одном правиле\u003C\u002Fh2>\u003Cp>Проблемы появляются, когда календарь проекта живёт отдельно от решений. Дата релиза приближается, а команда всё ещё обсуждает цель страницы, владельца контента или способ передачи заявки.\u003Cbr>\u003Cbr>Правило перехода простое: у текущего этапа есть проверяемый результат и человек, который его принимает. Тогда идея последовательно превращается в структуру, макеты, работающий сайт и управляемый релиз.\u003Cbr>\u003Cbr>Планируете корпоративный сайт? На странице \u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fqtim.pro\u002Fservices\u002Fcorporate\">разработки корпоративных сайтов\u003C\u002Fa> можно посмотреть базовый состав проекта и обсудить с нами маршрут от discovery до запуска.\u003Cbr> \u003C\u002Fp>",[123,130],{"id":124,"documentId":125,"title":126,"slug":127,"order":40,"createdAt":128,"updatedAt":128,"publishedAt":129,"locale":16},21,"yf23yooxmjrfe35xytsexltw","Веб-разработка","veb-razrabotka","2026-07-30T14:29:04.519Z","2026-07-30T14:29:04.572Z",{"id":131,"documentId":132,"title":133,"slug":134,"order":40,"createdAt":135,"updatedAt":135,"publishedAt":136,"locale":16},2,"ei24o3vyhndi1hqwqhnd61p0","Все","ALL","2026-02-25T07:47:50.713Z","2026-02-25T07:47:50.739Z",[],{"createdAt":139,"id":140,"documentId":141,"title":142,"date":77,"description":9,"order":40,"slug":143,"showOnMainPage":12,"updatedAt":144,"publishedAt":145,"locale":16,"cover":146,"content":180,"media_event":9,"media_areas":184,"seo":9,"localizations":193},"2026-09-11T14:35:28.405Z",311,"v3w411p7i1i1btgcmn7pwxl7","Цена уже изменилась, остаток ещё старый: где ломается единый кабинет селлера","edinyy-kabinet-sellera-dlya-marketpleysov","2026-09-14T15:33:57.800Z","2026-09-14T15:33:57.871Z",{"id":147,"documentId":148,"name":149,"alternativeText":9,"caption":9,"width":84,"height":85,"formats":150,"hash":175,"ext":88,"mime":91,"size":176,"url":177,"previewUrl":9,"provider":62,"provider_metadata":9,"createdAt":178,"updatedAt":178,"publishedAt":179},759,"zlci7esosz1u5selr9chmckx","Изображение Codex 14 сент. 2026 г., 15_53_15.png",{"large":151,"small":157,"medium":163,"thumbnail":169},{"ext":88,"url":152,"hash":153,"mime":91,"name":154,"path":9,"size":155,"width":32,"height":33,"sizeInBytes":156},"https:\u002F\u002Fstrapi.qtim.pro\u002Fuploads\u002Flarge_Izobrazhenie_Codex_14_sent_2026_g_15_53_15_b98646eba1.png","large_Izobrazhenie_Codex_14_sent_2026_g_15_53_15_b98646eba1","large_Изображение Codex 14 сент. 2026 г., 15_53_15.png",707.24,707241,{"ext":88,"url":158,"hash":159,"mime":91,"name":160,"path":9,"size":161,"width":40,"height":41,"sizeInBytes":162},"https:\u002F\u002Fstrapi.qtim.pro\u002Fuploads\u002Fsmall_Izobrazhenie_Codex_14_sent_2026_g_15_53_15_b98646eba1.png","small_Izobrazhenie_Codex_14_sent_2026_g_15_53_15_b98646eba1","small_Изображение Codex 14 сент. 2026 г., 15_53_15.png",198.34,198336,{"ext":88,"url":164,"hash":165,"mime":91,"name":166,"path":9,"size":167,"width":48,"height":49,"sizeInBytes":168},"https:\u002F\u002Fstrapi.qtim.pro\u002Fuploads\u002Fmedium_Izobrazhenie_Codex_14_sent_2026_g_15_53_15_b98646eba1.png","medium_Izobrazhenie_Codex_14_sent_2026_g_15_53_15_b98646eba1","medium_Изображение Codex 14 сент. 2026 г., 15_53_15.png",416.78,416779,{"ext":88,"url":170,"hash":171,"mime":91,"name":172,"path":9,"size":173,"width":56,"height":57,"sizeInBytes":174},"https:\u002F\u002Fstrapi.qtim.pro\u002Fuploads\u002Fthumbnail_Izobrazhenie_Codex_14_sent_2026_g_15_53_15_b98646eba1.png","thumbnail_Izobrazhenie_Codex_14_sent_2026_g_15_53_15_b98646eba1","thumbnail_Изображение Codex 14 сент. 2026 г., 15_53_15.png",54.68,54682,"Izobrazhenie_Codex_14_sent_2026_g_15_53_15_b98646eba1",533.26,"https:\u002F\u002Fstrapi.qtim.pro\u002Fuploads\u002FIzobrazhenie_Codex_14_sent_2026_g_15_53_15_b98646eba1.png","2026-09-14T15:32:02.256Z","2026-09-14T15:32:02.257Z",[181],{"__component":69,"id":182,"text":183},275,"\u003Cp>Менеджер обновил цену и увидел зелёную галочку. На соседней вкладке остаток всё ещё прежний, а в кабинете маркетплейса товар уже участвует в акции. В этот момент непонятно главное: данные отправлены, приняты или действительно применены?\u003C\u002Fp>\u003Cp>Обычный интерфейс скрывает рассинхронизацию за словом «успешно». Команда замечает её позже: когда заказ приходится отменять, скидка съедает маржу или бухгалтерия не находит закрывающий документ.\u003C\u002Fp>\u003Cp>Привет, я Антон Фокин, CEO Qtim. Расскажу, из каких состояний складывается единый кабинет селлера, почему одной интеграции с API недостаточно и с какой операции стоит начинать собственную систему.\u003C\u002Fp>\u003Ch2>Зелёная галочка скрывает четыре разных состояния\u003C\u002Fh2>\u003Cfigure class=\"image\">\u003Cimg alt=\"Изображение Codex 14 сент. 2026 г., 16_02_41.png\" src=\"https:\u002F\u002Fstrapi.qtim.pro\u002Fuploads\u002FIzobrazhenie_Codex_14_sent_2026_g_16_02_41_dbc0d0ee88.png\" srcset=\"https:\u002F\u002Fstrapi.qtim.pro\u002Fuploads\u002Fthumbnail_Izobrazhenie_Codex_14_sent_2026_g_16_02_41_dbc0d0ee88.png 245w, https:\u002F\u002Fstrapi.qtim.pro\u002Fuploads\u002Fsmall_Izobrazhenie_Codex_14_sent_2026_g_16_02_41_dbc0d0ee88.png 500w, https:\u002F\u002Fstrapi.qtim.pro\u002Fuploads\u002Fmedium_Izobrazhenie_Codex_14_sent_2026_g_16_02_41_dbc0d0ee88.png 750w, https:\u002F\u002Fstrapi.qtim.pro\u002Fuploads\u002Flarge_Izobrazhenie_Codex_14_sent_2026_g_16_02_41_dbc0d0ee88.png 1000w\" sizes=\"100vw\" width=\"1000\">\u003C\u002Ffigure>\u003Cp>Кнопка «Обновить цену» запускает цепочку. Кабинет формирует запрос, отправляет его на площадку, получает технический ответ, а затем ждёт результата обработки. На каждом шаге операция может остановиться.\u003C\u002Fp>\u003Cp>Поэтому у изменения цены должно быть хотя бы четыре понятных состояния:\u003C\u002Fp>\u003Cul>\u003Cli data-list-item-id=\"e335f7c2d899db237442db1ddf05e886d\">создано в кабинете;\u003C\u002Fli>\u003Cli data-list-item-id=\"e3bc8d42fac906ad05059812e9f27389f\">отправлено на площадку;\u003C\u002Fli>\u003Cli data-list-item-id=\"e75146700aaad6a671bd3ff4914280e7a\">принято в обработку;\u003C\u002Fli>\u003Cli data-list-item-id=\"e3e8409e9647980a896a25f5a809012cf\">применено или отклонено с причиной.\u003C\u002Fli>\u003C\u002Ful>\u003Cp>Если объединить их в одно «готово», интерфейс начинает врать. HTTP-ответ подтверждает доставку запроса, но ещё ничего не говорит о карточке товара. В \u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fdev.wildberries.ru\u002Fdocs\u002Fopenapi\u002Fwork-with-products\">документации WB API\u003C\u002Fa> для загрузки цен и скидок отдельно предусмотрена проверка обработанного запроса: часть товаров может не обновиться, и причину нужно получить после отправки.\u003C\u002Fp>\u003Cp>Похожая логика нужна для остатков, заказов и документов. Единый кабинет хранит идентификатор своей операции, идентификатор операции площадки, исходные данные, текущий статус и текст ошибки. Тогда менеджер видит, где именно остановился процесс, а разработчик может восстановить его по журналу событий.\u003C\u002Fp>\u003Cp>Второй вопрос — источник истины. Цена может рассчитываться в ERP или отдельном сервисе, физический остаток жить в 1С или WMS, а доступное к продаже количество зависеть от резервов и правил конкретного маркетплейса. Перед разработкой мы фиксируем владельца каждого поля. Иначе две системы начинают по очереди перезаписывать друг друга, а «последнее обновление» превращается в случайную победу одного канала.\u003C\u002Fp>\u003Ch2>Цена и остаток приезжают в витрину с разной скоростью\u003C\u002Fh2>\u003Cp>На экране цена и остаток стоят рядом, поэтому легко принять их за единый набор данных. Для интеграции это две независимые команды со своими ограничениями, очередями и ошибками. Так и возникает сценарий «Цена уже изменилась, остаток ещё старый»: обновления доходят до площадки и подтверждаются независимо.\u003C\u002Fp>\u003Cp>Маркетплейс может принять пакет цен, поставить его в обработку и вернуть итог позже. Запрос по остаткам способен пройти быстрее, но столкнуться с лимитом API при массовом обновлении. Официальная документация WB API отдельно описывает лимиты запросов и ответы 429 и 5xx. Такой ответ нельзя превращать в бесконечную серию повторов: она только усиливает нагрузку и отодвигает восстановление.\u003C\u002Fp>\u003Cp>Мы закладываем управляемую очередь. После временной ошибки операция ждёт следующей попытки с растущим интервалом. Постоянная ошибка — например, некорректное значение — попадает в очередь исключений с понятной причиной. Повторная отправка использует тот же ключ идемпотентности, чтобы восстановление связи не создало дубль.\u003C\u002Fp>\u003Cp>Для пользователя важны четыре времени: когда значение изменили в исходной системе, когда кабинет отправил его, когда площадка приняла запрос и когда результат подтвердился. Подпись «обновлено в 12:40» без уточнения события бесполезна. Она создаёт уверенность там, где пока есть только ожидание.\u003C\u002Fp>\u003Cp>На главном экране лучше показать простую связку: текущее значение в источнике, подтверждённое значение на площадке, время последней сверки и действие при ошибке. Расхождение тогда становится рабочей задачей, а не сюрпризом в отчёте.\u003C\u002Fp>\u003Ch2>Один заказ проходит через несколько словарей статусов\u003C\u002Fh2>\u003Cfigure class=\"image\">\u003Cimg alt=\"03-status-dictionaries-color-diorama-v4.png\" src=\"https:\u002F\u002Fstrapi.qtim.pro\u002Fuploads\u002F03_status_dictionaries_color_diorama_v4_7fc7037165.png\" srcset=\"https:\u002F\u002Fstrapi.qtim.pro\u002Fuploads\u002Fthumbnail_03_status_dictionaries_color_diorama_v4_7fc7037165.png 245w, https:\u002F\u002Fstrapi.qtim.pro\u002Fuploads\u002Fsmall_03_status_dictionaries_color_diorama_v4_7fc7037165.png 500w, https:\u002F\u002Fstrapi.qtim.pro\u002Fuploads\u002Fmedium_03_status_dictionaries_color_diorama_v4_7fc7037165.png 750w, https:\u002F\u002Fstrapi.qtim.pro\u002Fuploads\u002Flarge_03_status_dictionaries_color_diorama_v4_7fc7037165.png 1000w\" sizes=\"100vw\" width=\"1000\">\u003C\u002Ffigure>\u003Cp>С заказами сложнее: состояние меняется по обе стороны интеграции. Площадка создаёт заказ и переводит его по своей схеме. ERP резервирует товар. Склад подтверждает сборку. Служба доставки добавляет ещё один набор событий.\u003C\u002Fp>\u003Cp>\u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fwww.yandex.ru\u002Fdev\u002Fmarket\u002Fpartner-api\u002Fdoc\u002Fru\u002Fstep-by-step\u002Forders-receive\">API Яндекс Маркета\u003C\u002Fa> позволяет получать заказы через уведомления или регулярные запросы. Оба способа требуют контроля: уведомление может прийти повторно, а периодический опрос — временно не получить данные. Собственный кабинет должен принять событие один раз, сохранить исходный код площадки и перевести его во внутреннее состояние.\u003C\u002Fp>\u003Cp>Полностью сводить разные словари к пяти универсальным словам опасно. Статус «готов к отгрузке» на двух площадках может требовать разных действий и документов. Поэтому интерфейс показывает понятное бизнес-состояние, а внутри сохраняет внешний код и историю переходов. Поддержка сможет ответить, почему заказ оказался в текущей точке, не собирая картину по скриншотам.\u003C\u002Fp>\u003Cp>Остаток тоже нельзя хранить одним числом. Обычно команде нужны физическое количество, резерв, доступно к продаже и подтверждённое значение на каждой площадке. Формула доступного остатка должна находиться в одном месте. Когда её копируют в ERP, кабинет и интеграционный скрипт, расхождение становится вопросом времени.\u003C\u002Fp>\u003Cp>Здесь особенно важна идемпотентность. Повторное событие не должно повторно списывать товар, создавать второй документ или запускать ещё одну отгрузку. Для менеджера это незаметная техническая деталь. Для бизнеса — защита от отмен, двойных операций и долгого ручного разбора.\u003C\u002Fp>\u003Ch2>Файл сформирован — документ ещё не получен\u003C\u002Fh2>\u003Cfigure class=\"image\">\u003Cimg alt=\"Изображение Codex 14 сент. 2026 г., 16_20_12.png\" src=\"https:\u002F\u002Fstrapi.qtim.pro\u002Fuploads\u002FIzobrazhenie_Codex_14_sent_2026_g_16_20_12_507b78fc99.png\" srcset=\"https:\u002F\u002Fstrapi.qtim.pro\u002Fuploads\u002Fthumbnail_Izobrazhenie_Codex_14_sent_2026_g_16_20_12_507b78fc99.png 245w, https:\u002F\u002Fstrapi.qtim.pro\u002Fuploads\u002Fsmall_Izobrazhenie_Codex_14_sent_2026_g_16_20_12_507b78fc99.png 500w, https:\u002F\u002Fstrapi.qtim.pro\u002Fuploads\u002Fmedium_Izobrazhenie_Codex_14_sent_2026_g_16_20_12_507b78fc99.png 750w, https:\u002F\u002Fstrapi.qtim.pro\u002Fuploads\u002Flarge_Izobrazhenie_Codex_14_sent_2026_g_16_20_12_507b78fc99.png 1000w\" sizes=\"100vw\" width=\"1000\">\u003C\u002Ffigure>\u003Cp>Документы редко попадают в первый прототип, потому что команда сосредоточена на каталоге и заказах. Потом выясняется, что менеджер по-прежнему скачивает отчёты на каждой площадке, переименовывает файлы и сверяет периоды.\u003C\u002Fp>\u003Cp>Некоторые документы формируются асинхронно. В \u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fyandex.ru\u002Fdev\u002Fmarket\u002Fpartner-api\u002Fdoc\u002Fru\u002Fstep-by-step\u002Freports\">API Яндекс Маркета\u003C\u002Fa> отчёт сначала нужно запросить, затем дождаться готовности и только потом получить файл. Кнопка «Скачать» в собственном кабинете должна отражать эту цепочку: запрос создан, отчёт формируется, файл готов, генерация завершилась ошибкой.\u003C\u002Fp>\u003Cp>Сам файл — лишь часть объекта. Рядом нужны тип документа, площадка, юридическое лицо, период, версия, дата формирования и связь с заказами или выплатой. Если площадка пересобрала отчёт, кабинет обязан сохранить, какая версия ушла в бухгалтерию.\u003C\u002Fp>\u003Cp>Полезный интерфейс отвечает на три вопроса без переписки: за какой период документ, готов ли он и кто уже его выгрузил. Так раздел с файлами становится частью процесса, а не общей папкой с непонятными названиями.\u003C\u002Fp>\u003Ch2>Главный экран кабинета — очередь исключений\u003C\u002Fh2>\u003Cp>Первый макет единого кабинета часто строят вокруг графиков: выручка, число заказов, остатки по складам. Эти данные полезны руководителю, но операционная команда открывает систему ради другого. Ей нужно понять, что сегодня требует вмешательства.\u003C\u002Fp>\u003Cp>Мы выносим на первый экран:\u003C\u002Fp>\u003Cul>\u003Cli data-list-item-id=\"e1fed60ede1d2b15e30ff1ebe098f08fd\">цены, которые площадка отклонила;\u003C\u002Fli>\u003Cli data-list-item-id=\"e2451fd84c8265ae3f3d5c82d948e7522\">товары с расхождением остатков;\u003C\u002Fli>\u003Cli data-list-item-id=\"eba2896d13ec1f605326fbd98b764b1fe\">заказы, застрявшие между статусами;\u003C\u002Fli>\u003Cli data-list-item-id=\"ec754d80d048a2ee0acb0764feefb8626\">документы, которые не сформировались в ожидаемый срок.\u003C\u002Fli>\u003C\u002Ful>\u003Cp>Каждая строка ведёт к операции с историей: кто изменил данные, что отправил кабинет, какой ответ пришёл, сколько было попыток и что можно сделать сейчас. Для исправимой ошибки нужна кнопка повторной отправки. Для ошибки в исходных данных — ссылка на поле, которое следует изменить. Для недоступного API — время следующей попытки.\u003C\u002Fp>\u003Cp>Журнал аудита здесь важнее красивой ленты активности. Он связывает действие сотрудника, версию данных и внешний ответ. Без этой связи спор «кто поменял цену» заканчивается поиском по чатам и логам нескольких систем.\u003C\u002Fp>\u003Cp>Роли тоже проектируют вокруг операций. Категорийный менеджер меняет цены, сотрудник склада работает с отгрузкой, бухгалтер скачивает документы, руководитель видит сводную картину. Возможность посмотреть данные ещё не означает право повторить запрос или отменить действие.\u003C\u002Fp>\u003Ch2>Первый релиз должен провести одну операцию до конца\u003C\u002Fh2>\u003Cp>Попытка сразу объединить каталог, аналитику, рекламу, финансы и документы растягивает проект и откладывает проверку ключевой гипотезы. Для первого релиза лучше выбрать одну бизнес-операцию и провести её через весь контур.\u003C\u002Fp>\u003Cp>Например: менеджер меняет цену в исходной системе, кабинет отправляет обновление на две площадки, получает итоговые статусы, показывает расхождения и позволяет безопасно повторить неуспешную операцию. В этом сценарии уже проверяются модель данных, очередь, права, журнал и обработка ошибок. Следующий поток можно добавлять на готовую основу.\u003C\u002Fp>\u003Cp>В \u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fqtim.pro\u002Fprojects\u002Fhotz\">проекте HOTZ\u003C\u002Fa> мы строили смежный механизм: единый каталог и двусторонний обмен с 1С для товаров, остатков и заказов. В \u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fqtim.pro\u002Fprojects\u002Fteplomash\">проекте для «Тепломаш»\u003C\u002Fa> общая платформа синхронизировала каталоги, цены, остатки и обработку заказов трёх брендов. Это не кабинеты селлера, однако в них виден тот же архитектурный принцип: один слой координирует данные нескольких систем и хранит правила обмена в понятном месте.\u003C\u002Fp>\u003Cp>Собственная разработка нужна не каждому продавцу. При одной площадке, небольшом ассортименте и простых процессах команде часто достаточно штатного кабинета или готового коннектора. Свой слой оправдан, когда одна операция проходит через несколько площадок, ERP, склад и документооборот, а цена расхождения выше стоимости поддержки системы.\u003C\u002Fp>\u003Cp>Критерий можно сформулировать в одну строку: если сотрудник завершает одну бизнес-операцию в нескольких системах, единому кабинету есть что объединять.\u003C\u002Fp>\u003Cp>Начать стоит с карты источников данных и одного сквозного сценария. На странице о \u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fqtim.pro\u002Fservices\u002Fcabinets\">разработке личных кабинетов и экосистем\u003C\u002Fa> мы собрали, какие интеграции и операционные механизмы обычно входят в такой контур.\u003C\u002Fp>",[185,192],{"id":186,"documentId":187,"title":188,"slug":189,"order":40,"createdAt":190,"updatedAt":190,"publishedAt":191,"locale":16},33,"xhke7f1vzoqyx9nzqc1sukc6","e-commerce","ecommerce-blog","2026-08-31T12:06:40.235Z","2026-08-31T12:06:40.258Z",{"id":131,"documentId":132,"title":133,"slug":134,"order":40,"createdAt":135,"updatedAt":135,"publishedAt":136,"locale":16},[],{"createdAt":195,"id":196,"documentId":197,"title":198,"date":199,"description":9,"order":40,"slug":200,"showOnMainPage":12,"updatedAt":195,"publishedAt":201,"locale":16,"cover":202,"content":236,"media_event":9,"media_areas":240,"seo":9,"localizations":243},"2026-09-13T23:38:47.063Z",299,"vc9i1ztfpn2yrd5nx782zp3z","Этапы разработки дизайна сайта: как создать привлекательный и функциональный веб-дизайн","2026-09-13","etapy-razrabotki-dizayna-sayta-kak-sozdat-privlekatelnyy-i-funktsionalnyy-veb-dizayn","2026-09-13T23:38:47.130Z",{"id":203,"documentId":204,"name":205,"alternativeText":9,"caption":9,"width":84,"height":85,"formats":206,"hash":231,"ext":88,"mime":91,"size":232,"url":233,"previewUrl":9,"provider":62,"provider_metadata":9,"createdAt":234,"updatedAt":234,"publishedAt":235},738,"y2i0amroaoyllxjsiquxaouu","Изображение Codex 14 сент. 2026 г., 00_49_45.png",{"large":207,"small":213,"medium":219,"thumbnail":225},{"ext":88,"url":208,"hash":209,"mime":91,"name":210,"path":9,"size":211,"width":32,"height":33,"sizeInBytes":212},"https:\u002F\u002Fstrapi.qtim.pro\u002Fuploads\u002Flarge_Izobrazhenie_Codex_14_sent_2026_g_00_49_45_11b59ce225.png","large_Izobrazhenie_Codex_14_sent_2026_g_00_49_45_11b59ce225","large_Изображение Codex 14 сент. 2026 г., 00_49_45.png",419.53,419529,{"ext":88,"url":214,"hash":215,"mime":91,"name":216,"path":9,"size":217,"width":40,"height":41,"sizeInBytes":218},"https:\u002F\u002Fstrapi.qtim.pro\u002Fuploads\u002Fsmall_Izobrazhenie_Codex_14_sent_2026_g_00_49_45_11b59ce225.png","small_Izobrazhenie_Codex_14_sent_2026_g_00_49_45_11b59ce225","small_Изображение Codex 14 сент. 2026 г., 00_49_45.png",116.49,116494,{"ext":88,"url":220,"hash":221,"mime":91,"name":222,"path":9,"size":223,"width":48,"height":49,"sizeInBytes":224},"https:\u002F\u002Fstrapi.qtim.pro\u002Fuploads\u002Fmedium_Izobrazhenie_Codex_14_sent_2026_g_00_49_45_11b59ce225.png","medium_Izobrazhenie_Codex_14_sent_2026_g_00_49_45_11b59ce225","medium_Изображение Codex 14 сент. 2026 г., 00_49_45.png",244.51,244507,{"ext":88,"url":226,"hash":227,"mime":91,"name":228,"path":9,"size":229,"width":56,"height":57,"sizeInBytes":230},"https:\u002F\u002Fstrapi.qtim.pro\u002Fuploads\u002Fthumbnail_Izobrazhenie_Codex_14_sent_2026_g_00_49_45_11b59ce225.png","thumbnail_Izobrazhenie_Codex_14_sent_2026_g_00_49_45_11b59ce225","thumbnail_Изображение Codex 14 сент. 2026 г., 00_49_45.png",34.39,34386,"Izobrazhenie_Codex_14_sent_2026_g_00_49_45_11b59ce225",323.56,"https:\u002F\u002Fstrapi.qtim.pro\u002Fuploads\u002FIzobrazhenie_Codex_14_sent_2026_g_00_49_45_11b59ce225.png","2026-09-13T23:37:51.942Z","2026-09-13T23:37:51.948Z",[237],{"__component":69,"id":238,"text":239},263,"\u003Cp>На одном экране команда спорит о форме кнопки. На соседнем всё ещё нет сообщения об ошибке, мобильного меню и ответа на простой вопрос: что произойдёт после отправки формы. Главная страница выглядит убедительно, однако весь сайт пока держится на догадках.\u003C\u002Fp>\u003Cp>Такой разрыв появляется, когда дизайн воспринимают как последовательность красивых макетов. В рабочем проекте одновременно развиваются три контура: смысл, поведение и визуальная система. Они сходятся в одном интерфейсе, поэтому слабое решение в любом из них быстро проявится в остальных.\u003C\u002Fp>\u003Cp>Разберём этапы разработки дизайна сайта через эти три контура. Эта схема помогает заказчику оценивать работу по понятным признакам, а команде — не возвращаться к структуре и сценариям после того, как десятки экранов уже отрисованы.\u003C\u002Fp>\u003Ch2>Первый экран появляется после ответа на три неприятных вопроса\u003C\u002Fh2>\u003Cp>До макетов нужно договориться, зачем сайту существовать. Конкретный ответ звучит как действие и продолжение бизнес-процесса: посетитель выбирает услугу и оставляет заявку, покупатель оформляет заказ, кандидат находит вакансию и отправляет резюме. Формулировка «рассказать о компании» не задаёт ни маршрута, ни критерия приёмки.\u003C\u002Fp>\u003Cp>Второй вопрос — кто принимает решение. На корпоративный сайт могут приходить потенциальный клиент, партнёр, журналист и соискатель. У каждого свой контекст, словарь и нужная глубина информации. Все аудитории нельзя сделать главными одновременно: приоритет определяет навигацию, порядок блоков и заметность целевых действий.\u003C\u002Fp>\u003Cp>Третий вопрос касается ограничений. Какие интеграции обязательны? Кто готовит тексты и изображения? Какие разделы будет обновлять редактор? Нужны ли разные языковые версии, личный кабинет, каталог или поиск? Ответы влияют на объём проектирования сильнее, чем пожелание сделать сайт «современным».\u003C\u002Fp>\u003Cp>Для старта достаточно короткого брифа, где зафиксированы цель, аудитория, ключевой сценарий, ограничения и ответственный за согласование. Двадцатистраничный документ не обязателен. Обязательна ясность: какое действие совершает человек и какой процесс продолжается после него.\u003C\u002Fp>\u003Ch2>Три контура дизайна сходятся в одном макете\u003C\u002Fh2>\u003Cp>Этапы редко идут строго один за другим. Исследование меняет структуру, прототип уточняет содержание, визуальная концепция выявляет ограничения компонента. Чтобы не потеряться в итерациях, удобно смотреть на проект как на три связанных контура.\u003C\u002Fp>\u003Cul>\u003Cli data-list-item-id=\"e79bb4f94737fe76485ed0ef3e8c78f8d\">Контур смысла отвечает за то, что сайт сообщает, кому и в какой последовательности.\u003C\u002Fli>\u003Cli data-list-item-id=\"ea2ed1bd14ec376997957c08d0d0af7e2\">Контур поведения описывает маршруты, действия, состояния и реакцию интерфейса.\u003C\u002Fli>\u003Cli data-list-item-id=\"e6868afd279db8a2504f715ffc35ec0da\">Контур формы превращает решения в визуальные правила, компоненты и спецификацию для разработки.\u003C\u002Fli>\u003C\u002Ful>\u003Cp>В центре схемы находится ключевой пользовательский сценарий, и главная страница становится одним из его экранов. По нему видно, поддерживают ли структура, тексты, интерактивность и оформление одну задачу.\u003C\u002Fp>\u003Ch2>Контур смысла: структура растёт из решения, которое должен принять человек\u003C\u002Fh2>\u003Cp>Сначала команда собирает основания для проектирования. Для действующего сайта полезны веб-аналитика, поисковые запросы, обращения в поддержку, записи интервью и причины отказов. Для нового продукта — интервью, данные продаж, вопросы клиентов и ограничения бизнес-модели. Источники выбирают под задачу; лишний объём исследования ценности не добавляет.\u003C\u002Fp>\u003Cp>У конкурентов изучают механику: как они делят каталог, объясняют условия, снимают сомнения и ведут к следующему шагу. Копирование цветов и композиции почти ничего не говорит о причинах этих решений. Гораздо полезнее заметить устойчивые ожидания рынка и места, где пользователь вынужден догадываться.\u003C\u002Fp>\u003Cp>Затем появляются приоритетные сценарии и карта сайта. Карта сайта фиксирует систему переходов между страницами. Человек приходит из поиска, рекламы или рекомендации, находит нужный уровень подробности, сравнивает варианты и понимает следующий шаг. Каждая страница получает роль в этом маршруте.\u003C\u002Fp>\u003Cp>Структуру проверяют на реальном содержании. Заголовки, характеристики, ограничения, примеры и юридические формулировки сразу показывают, где блок слишком тесный, а соседние страницы повторяют друг друга. Текст-заполнитель маскирует такие проблемы и переносит их на позднюю стадию.\u003C\u002Fp>\u003Cp>Здесь же закладывают поисковую логику. У страницы должна быть своя тема, понятный заголовок первого уровня и место в иерархии. Мобильная версия сохраняет основной контент и заголовки десктопа — это соответствует \u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fdevelopers.google.com\u002Fsearch\u002Fdocs\u002Fcrawling-indexing\u002Fmobile\u002Fmobile-sites-mobile-first-indexing\">рекомендациям Google\u003C\u002Fa> для сайтов с mobile-first индексацией.\u003C\u002Fp>\u003Cp>Контур смысла готов, когда для ключевых страниц понятны аудитория, вопрос читателя, необходимый контент и следующий переход. После этого визуальная иерархия получает опору.\u003C\u002Fp>\u003Ch2>Контур поведения: прототип обязан пережить ошибку\u003C\u002Fh2>\u003Cp>Прототип показывает интерфейс до выбора шрифтов, цвета и изображений. В нём видны порядок блоков, навигация, формы, переходы и реакция системы. Серые схемы ценны своей дешевизной: переставить шаг или убрать лишний экран проще до того, как решение обрастёт деталями.\u003C\u002Fp>\u003Cp>Статичного прототипа хватает для простого лендинга. Сложный маршрут нужно пройти. Кликабельная версия позволяет проверить подбор тарифа, оформление заказа, регистрацию, отправку заявки или работу фильтра. Команда видит последовательность решений пользователя между экранами.\u003C\u002Fp>\u003Cp>Главная проверка начинается за пределами успешного пути. Что увидит человек при неверном формате телефона? Как выглядит пустой результат поиска? Сохранится ли введённое после ошибки? Что происходит при медленной загрузке, длинном названии или отсутствии изображения? Эти состояния определяют качество опыта сильнее, чем идеальная демонстрация главной страницы.\u003C\u002Fp>\u003Cp>\u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fwww.w3.org\u002FWAI\u002Ftest-evaluate\u002Finvolving-users\u002F\">W3C рекомендует\u003C\u002Fa> подключать пользователей к оценке интерфейса на ранних стадиях и проводить проверки уже на прототипах. Для этого участнику дают задачу, наблюдают за действиями и фиксируют места, где он останавливается, возвращается или просит подсказку. Несколько наблюдений не заменяют исследование аудитории, зато быстро вскрывают непонятные подписи и пропущенные шаги.\u003C\u002Fp>\u003Cp>После теста правят конкретный механизм: название пункта, порядок полей, заметность действия, обратную связь системы. Формулировка «пользователю было неудобно» слишком общая. Команде нужен наблюдаемый сбой и понятное изменение, которое можно проверить повторно.\u003C\u002Fp>\u003Cp>Мы считаем прототип сырым, пока автор макета вынужден объяснять, куда нажать. Рабочий сценарий должен читаться без устного сопровождения и сохранять логику при ошибке.\u003C\u002Fp>\u003Ch2>Контур формы: концепция должна выдержать второй экран\u003C\u002Fh2>\u003Cp>Визуальная концепция появляется после того, как понятны смысл и поведение. Она задаёт типографику, цвет, сетку, характер изображений, плотность информации и принципы движения. Её задача — управлять вниманием и выражать позицию бренда в рамках пользовательского маршрута.\u003C\u002Fp>\u003Cp>Одного эффектного первого экрана недостаточно. Мы показываем направление на разных типах страниц: например, на главной, странице услуги, длинной статье и форме. Так быстрее обнаруживается концепция, которая работает только в рекламной композиции и рассыпается в каталоге или личном кабинете.\u003C\u002Fp>\u003Cp>После утверждения направления решения превращаются в систему. В UI-kit входят кнопки, поля, карточки, меню, таблицы, уведомления и модальные окна. Для каждого компонента описывают варианты и состояния: обычное, активное, при наведении, в фокусе, при ошибке, загрузке и недоступности.\u003C\u002Fp>\u003Cp>Адаптивность тоже задаётся правилами. На маленьком экране блоки меняют порядок, таблицы получают другой формат, элементы остаются удобными для касания, а важный контент не исчезает. \u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fdevelopers.google.com\u002Fsearch\u002Fdocs\u002Fcrawling-indexing\u002Fmobile\u002Fmobile-sites-mobile-first-indexing\">Google рекомендует\u003C\u002Fa> адаптивный дизайн как наиболее простой в реализации и поддержке вариант для мобильных сайтов.\u003C\u002Fp>\u003Cp>Доступность проверяют внутри системы на каждом шаге проекта. \u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fwww.w3.org\u002FTR\u002FWCAG22\u002F\">WCAG 2.2\u003C\u002Fa> устанавливает минимальный контраст 4,5:1 для обычного текста и целевой размер интерактивной области не меньше 24 × 24 CSS-пикселей с оговорёнными исключениями. Эти требования влияют на цвета, размеры и состояния компонентов.\u003C\u002Fp>\u003Cp>Цена декоративного решения хорошо видна на фокусе клавиатуры. По данным \u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Falmanac.httparchive.org\u002Fen\u002F2025\u002Faccessibility\">Web Almanac\u003C\u002Fa> за 2025 год, 67% проверенных сайтов явно убирали стандартную обводку фокуса. Интерфейс мог выглядеть чище, но часть пользователей теряла указатель текущего элемента.\u003C\u002Fp>\u003Cp>\u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fwww.w3.org\u002FWAI\u002Fplanning-and-managing\u002F\">Рекомендации W3C\u003C\u002Fa> предлагают учитывать доступность на протяжении всего производства сайта и регулярно её проверять. Тогда исправление касается одного правила компонента. В финале тот же дефект пришлось бы искать на множестве уже свёрстанных экранов.\u003C\u002Fp>\u003Cp>Контур формы готов, когда новый экран можно собрать по существующим правилам без отдельного творческого согласования. Целостность сайта рождается именно из повторяемости решений.\u003C\u002Fp>\u003Ch2>Макет заканчивается на тестовом стенде\u003C\u002Fh2>\u003Cp>Передача в разработку — часть дизайна. В макетах должны быть понятны названия компонентов, варианты, размеры, сетки, отступы, экспорт графики и доступы к шрифтам. Нестандартное поведение сопровождают короткими пояснениями: как закрепляется меню, обрезается изображение, отправляется форма и восстанавливаются данные.\u003C\u002Fp>\u003Cp>Разработчик и дизайнер разбирают спорные места до вёрстки. Это помогает заранее упростить тяжёлую анимацию, уточнить зависимость состояний или выбрать устойчивое поведение для разных браузеров. Договорённость фиксируют рядом с компонентом, чтобы она не потерялась в переписке.\u003C\u002Fp>\u003Cp>Когда страницы появляются на тестовом стенде, дизайнер проверяет уже работающий интерфейс. В фокусе иерархия, сетка, реальные переносы текста, состояния, разные ширины экрана и управление с клавиатуры. Макет здесь служит системой правил. Точное копирование каждого пикселя уступает проверке поведения и визуальной иерархии.\u003C\u002Fp>\u003Cp>Этап закрывает принятая реализация ключевых страниц. До этого момента дизайн остаётся гипотезой о том, как система будет выглядеть и вести себя в коде.\u003C\u002Fp>\u003Ch2>Как принять дизайн за два созвона, а не за десять кругов правок\u003C\u002Fh2>\u003Cp>Количество согласований сокращается, когда у каждого созвона есть свой предмет. На первой встрече утверждают цель, аудиторию, маршрут и состав содержания. Цвет и изображения пока не обсуждают: для них ещё нет устойчивой основы.\u003C\u002Fp>\u003Cp>На второй встрече команда рассматривает визуальное направление на нескольких типах экранов, адаптив и состояния компонентов. Обсуждение строится вокруг функции решения: куда падает внимание, какое действие заметно, как система отвечает и повторяется ли правило на других страницах.\u003C\u002Fp>\u003Cp>Перед приёмкой полезно пройти четыре проверки:\u003C\u002Fp>\u003Cul>\u003Cli data-list-item-id=\"e2d0ce25005ee051fa52576ea96be5e2f\">главное действие страницы понятно без пояснения автора;\u003C\u002Fli>\u003Cli data-list-item-id=\"ef36f91122ea314ae5432f50ceb7104a2\">сценарий работает при ошибке, пустых данных и на мобильном экране;\u003C\u002Fli>\u003Cli data-list-item-id=\"e7b54df0d8edd546124df1f66bbd3a6fd\">визуальные правила повторяются на разных типах страниц;\u003C\u002Fli>\u003Cli data-list-item-id=\"e73f0b31345882ea76aebf8e5be515867\">разработчику хватает компонентов и спецификации для реализации.\u003C\u002Fli>\u003C\u002Ful>\u003Cp>Замечание привязывают к одной из этих проверок. Так фраза «хочется посвежее» превращается в предметный разговор о контрасте, иерархии, образах или характере движения.\u003C\u002Fp>\u003Ch2>Когда полный цикл можно сократить\u003C\u002Fh2>\u003Cp>Небольшому лендингу с готовым содержанием и одним сценарием не всегда нужны отдельные недели на каждый контур. Команда может почти одновременно уточнить задачу, собрать схему страницы и показать визуальное направление.\u003C\u002Fp>\u003Cp>Проекты с несколькими аудиториями, каталогом, личным кабинетом, интеграциями или большой контентной системой требуют развёрнутой проверки. Сокращение процесса в таком случае означает меньше данных для решения и больше неизвестных в разработке.\u003C\u002Fp>\u003Cp>Этап объединяют осознанно: команда называет риск и способ проверки, который остаётся. Скорость появляется за счёт меньшего объёма задачи. Неразобранные вопросы в вёрстке только отложат обсуждение.\u003C\u002Fp>\u003Ch2>Готовность дизайна видна по трём вещам\u003C\u002Fh2>\u003Cp>У страницы есть понятная задача, ключевой сценарий проходит вместе с ошибками, а визуальные правила воспроизводятся в коде. Эти три признака связывают привлекательность с функциональностью и дают заказчику основу для приёмки без спора о вкусах.\u003C\u002Fp>\u003Cp>Если планируете новый сайт от прототипа до запуска, посмотрите, как у нас устроена \u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fqtim.pro\u002Fservices\u002Fcorporate\">разработка корпоративных сайтов\u003C\u002Fa>. Для первого разговора достаточно цели, аудитории и одного ключевого сценария.\u003C\u002Fp>\u003Cdiv style=\"-webkit-text-stroke-width:0px;color:rgb(0, 0, 0);font-family:Times;font-size:medium;font-style:normal;font-variant-caps:normal;font-variant-ligatures:normal;font-weight:400;inset:0px;letter-spacing:normal;orphans:2;pointer-events:none;position:fixed;text-align:start;text-decoration-color:initial;text-decoration-style:initial;text-decoration-thickness:initial;text-indent:0px;text-transform:none;white-space:normal;widows:2;word-spacing:0px;z-index:2147483647;\" id=\"codex-browser-sidebar-comments-root\">\u003Cdiv> \u003C\u002Fdiv>\u003C\u002Fdiv>",[241,242],{"id":124,"documentId":125,"title":126,"slug":127,"order":40,"createdAt":128,"updatedAt":128,"publishedAt":129,"locale":16},{"id":131,"documentId":132,"title":133,"slug":134,"order":40,"createdAt":135,"updatedAt":135,"publishedAt":136,"locale":16},[]]