[{"data":1,"prerenderedAt":124},["ShallowReactive",2],{"$fBBQ5ulyG5jVWbIBJe3r8F-kTKQKf1scMJiu0B6qzX5k":3,"$f7AVZHmPutZ23_8XKkLbDtEszKCuiY3yPjIDp9eRXGag":5,"$fgGVNONxPtmbP_wvUQsdK72ghrAd6murDDymC3N1LiHg":7,"$fCQh-JWaO5ySnRycZDiT3Qhfw5YpYNP8xJkbnsimggA4":100},{"data":4},[],{"data":6},[],{"data":8,"meta":96},[9],{"id":10,"documentId":11,"title":12,"seo_title":13,"summary":14,"seo_description":15,"slug":16,"published_date":17,"body":18,"content":19,"createdAt":35,"updatedAt":36,"publishedAt":37,"blogauthor":38,"cover":47,"categories":85},327,"lruxexelyn19uak89r6dney5","Что такое OpenSpec? Полный гайд по Spec-Driven Development","Что такое OpenSpec: гайд по Spec-Driven Development","Разбираем, зачем AI-агенту спецификации, как устроен процесс в OpenSpec и как с его помощью реализовать новую функциональность от требований до кода.","Гайд по Spec-Driven Development и OpenSpec: требования, спецификации и критерии приёмки, этапы Propose, Apply, Sync и Archive на примере новой функции.","chto-takoe-openspec-polnyj-gajd-po-spec-driven-development","2026-09-28","Мы всё чаще слышим о том, что та или иная компания внедряет Spec-Driven Development (SDD), а чаще всего именно OpenSpec, в свои процессы разработки ПО. Где-то это пока эксперимент нескольких команд, а где-то спецификация уже становится обязательной точкой входа в любую задачу.\n\nПри этом мало кто из разработчиков понимает, что именно означает разработка с AI-агентом от спецификации, чем спецификации помогают на практике и какие особенности появляются при работе именно с OpenSpec. Нередко всё представление о подходе сводится к тому, что перед написанием кода агент должен создать ещё несколько Markdown-файлов.\n\nТак вот, устраивайтесь поудобнее. В этой статье мы наконец разложим по полочкам, зачем нужны все эти документы, разберёмся, как выглядит процесс разработки от спецификации, и попробуем реализовать новую функциональность с помощью [OpenSpec](https:\u002F\u002Fopenspec.dev\u002F).\n\n> _В этой статье я рассматриваю OpenSpec только на этапе разработки: от получения требований до реализации. Поиск и проверку продуктовых идей, а также согласование требований за пределами репозитория оставим за скобками._\n\n\u003Ch2 id=\"nemnogo-teorii\">Немного теории\u003C\u002Fh2>\n\nЕсли вы уже хорошо представляете, что такое спецификация, требование и критерии приёмки, смело пропускайте эту главу и переходите сразу к разделу про OpenSpec. Здесь мы ненадолго остановимся на базовых терминах, чтобы дальше говорить на одном языке.\n\nНачнём с понятия «требование». Требование — это описание того, что должна делать система. Хорошее требование описывает наблюдаемый и проверяемый результат.\n\nТребования бывают разного уровня:\n\n- **Бизнес-требования** объясняют, зачем компании нужно изменение и какого результата она хочет достичь\n- **Пользовательские требования** описывают, что пользователь должен иметь возможность сделать с помощью системы\n- **Системные требования** определяют, как система должна вести себя, чтобы выполнить пользовательские и бизнес-требования\n- **Нефункциональные\u002Fтехнические требования** фиксируют измеримые характеристики и ограничения реализации: производительность, нагрузку, технологии, протоколы, архитектурные правила и требования к инфраструктуре\n\nРазработчик в основном работает с системными и нефункциональными\u002Fтехническими требованиями: либо реализует уже сформулированные, либо формирует их на основе пользовательских и бизнес-требований.\n\nВообще при описании задачи стараются выдерживать единый уровень абстракции требований. Поэтому часто говорят об их иерархии: бизнес-требования задают цель, пользовательские — ожидаемый сценарий, а системные и нефункциональные\u002Fтехнические постепенно уточняют, как система должна эту цель поддержать. Но чтобы не превращать статью в академическое изложение, давайте разберёмся на примере.\n\nПредположим, мы разрабатываем систему для ветеринарной клиники. На уровне бизнес-требования её владелец формулирует цель: клинике нужна система учёта владельцев животных, самих животных и истории их посещений.\n\nИз этой цели появляются пользовательские требования. Например, администратор клиники должен иметь возможность вести реестры владельцев, животных и визитов. Здесь же описываем, какую информацию пользователь хочет хранить в каждом из них.\n\nДальше формируем системные требования: как именно администратор создаёт владельца, добавляет ему домашних животных, регистрирует визит и редактирует его данные. На этом уровне уже могут появиться пользовательские сценарии и mockup-ы интерфейсов.\n\nОтдельно формируем нефункциональные\u002Fтехнические требования: одновременно с системой могут работать до десяти администраторов, а время отклика интерфейса не должно превышать 100 мс. Сюда же могут входить ограничения на технологии, протоколы интеграции и архитектуру. Важнее всего, чтобы каждое требование было понятно и его можно было проверить.\n\n![Иерархия требований на примере ветеринарной клиники]({{strapiUrl}}\u002Fuploads\u002Fdeb07c8d9ab3f3f48b9db304ec0ff48c_da7e08a286.webp)\n\nТак вот, набор связанных требований примерно одного уровня абстракции — хотя на практике выдержать этот уровень удаётся не всегда — и можно назвать спецификацией.\n\nЗафиксируем: спецификация — это документ или набор документов, в котором собраны связанные требования к системе. В зависимости от уровня она может описывать бизнес-цели, пользовательские возможности, поведение системы либо нефункциональные и технические ограничения. Главное, чтобы требования не противоречили друг другу, оставались на сопоставимом уровне абстракции и описывали проверяемый результат.\n\n> Мы развиваем собственный [мультиагентный AI-плагин](\u002Fblog\u002Freliz-openide-claude-code-codex-opencode-i-cursor-pryamo-v-ide\u002F), и поддержка Spec-Driven Development – это одно из наших приоритетных направлений.\n>\n> Все примеры и скриншоты ниже сделаны в [OpenIDE](https:\u002F\u002Fopenide.ru\u002F) с нашим AI-плагином. Подробнее о плагине и самой IDE можно [прочитать тут](\u002Fblog\u002Freliz-openide-claude-code-codex-opencode-i-cursor-pryamo-v-ide\u002F).\n\n![]({{strapiUrl}}\u002Fuploads\u002Fc1c1afed2c73c5a8779938a0fed85fee_773789d44c.webp)\n\n\u003Ch2 id=\"openspec\">OpenSpec\u003C\u002Fh2>\n\n[OpenSpec](https:\u002F\u002Fopenspec.dev\u002F) — это открытый фреймворк для Spec-Driven Development. Он помогает фиксировать требования в спецификациях и поддерживать их актуальность на всём жизненном цикле: от момента, когда идея нового функционала только возникла в голове продукта, до её реализации в приложении. В OpenSpec каждое требование описывает ожидаемое поведение системы и дополняется сценариями с критериями приёмки.\n\nВ OpenSpec есть два вида спецификаций: main specs и delta specs. Main specs хранят описание текущего поведения системы и выступают источником истины (source of truth). Delta specs создаются для конкретного изменения и описывают только разницу между текущим и желаемым состоянием: какие требования нужно добавить, изменить, удалить или переименовать.\n\n![Delta specs и main specs]({{strapiUrl}}\u002Fuploads\u002F2db7d8af8a76d502b1ccbbb9898e50d2_566e45988e.webp)\n\nСама спецификация состоит из набора требований (requirements), и у каждого требования должен быть хотя бы один сценарий (scenario). И требования, и сценарии оформляются отдельными заголовками: ### Requirement: и #### Scenario: соответственно. Требование описывает одно наблюдаемое и проверяемое поведение системы, формулируется через SHALL или MUST и не содержит деталей реализации. Например: The system SHALL return the collection of all stored veterinarians.\n\nСценарий, в свою очередь, задаёт критерии приёмки требования и описывает конкретные условия и ожидаемый результат в формате GIVEN\u002FWHEN\u002FTHEN — либо WHEN\u002FTHEN, если предусловий нет. Например, сценарий List with existing records определяет, что запрос GET \u002Fapi\u002Fvets при наличии ветеринаров должен вернуть 200 OK и JSON-массив со всеми записями.\n\n![Пример спецификации OpenSpec с требованиями и сценариями]({{strapiUrl}}\u002Fuploads\u002Fd687a826140989fee800d50d797890b2_32417417e7.webp)\n\nНа первый взгляд может показаться, что эти требования и сценарии слишком очевидны. Но, во-первых, очевидные вещи тоже нужно где-то зафиксировать. Во-вторых, OpenSpec сгенерировал их самостоятельно — видимо, они ему всё-таки нужны. А поскольку они корректно описывают, как должно работать наше приложение, оставим их как есть.\n\nЕстественно, в эпоху AI руками мы пишем разве что промпты — да и те иногда просто наговариваем. Поэтому самое время разобраться, как генерировать спецификации с помощью OpenSpec.\n\n\u003Ch3 id=\"openspec-change\">OpenSpec Change\u003C\u002Fh3>\n\nЛюбая доработка в OpenSpec осуществляется через создание «изменения» (change). Внутри него OpenSpec хранит delta spec и связанные с доработкой артефакты. По умолчанию это proposal — фиксирует намерение и границы изменения; design — описывает техническое решение; tasks — задаёт последовательность работ, которой будет следовать агент. Этот список не исчерпывающий: при необходимости его можно дополнить артефактами, которые нужны именно вам.\n\n![OpenSpec change artifacts]({{strapiUrl}}\u002Fuploads\u002F803efe768c05722e7ec1c7d31d1f565d_75ed63ec0c.webp)\n\nДавайте создадим наше первое изменение. В качестве примера будем разрабатывать типовое приложение — ветеринарную клинику. За основу возьмём чистый проект на Spring Boot 4.1.1 и Java 26 с подключёнными Spring Web MVC, Spring Data JPA, Validation и PostgreSQL. Пока это пустая заготовка без доменной модели и endpoint-ов. Первым изменением добавим хранение информации о ветеринарах и CRUD REST API для работы с ними.\n\nНо прежде чем создавать первое изменение (change), необходимо инициализировать OpenSpec в репозитории.\n\nДля этого нам потребуется OpenSpec CLI. Инструкцию по установке для вашей платформы и ОС можно найти в [официальной документации](https:\u002F\u002Fopenspec.dev\u002Fdocs\u002Finstallation).\n\nДалее выполняем команду openspec init и выбираем агентов, которых будем использовать при разработке приложения.\n\n![Инициализация OpenSpec в OpenIDE]({{strapiUrl}}\u002Fuploads\u002F511312b354852f16bf53abc1f921ee3b_a0d4da9ed7.webp)\n\nЧто произошло под капотом? openspec init создал в корне репозитория каталог openspec\u002F, в котором будут храниться конфигурация проекта, актуальные спецификации и будущие изменения. Заодно CLI установил для выбранных агентов skill-ы и slash-команды. Спецификаций на этом этапе ещё нет: init только подготовил структуру проекта и инструкции, по которым будут работать агенты.\n\nДальше пройдём полный цикл изменения, состоящий из трёх этапов: Propose, Apply и Archive. Каждый из них разберём отдельно.\n\n![Стандартный процесс OpenSpec]({{strapiUrl}}\u002Fuploads\u002Fa45eef0c624e729596519abf6ebc2be9_3d26f74f6d.webp)\n\n#### Propose\n\nЧтобы создать первое изменение, воспользуемся командой \u002Fopsx:propose и передадим ей промпт с описанием того, что хотим изменить в приложении.\n\n```\n\u002Fopsx:propose Добавь модель для хранения информации о ветеринарах и CRUD REST API для создания, получения, изменения и удаления записей о них.\n```\n\n![Запуск opsx propose в OpenIDE]({{strapiUrl}}\u002Fuploads\u002F5dbefcc2fd9d307a7cbcf85d5fd83a9f_6295265a2c.webp)\n\nВ реальном проекте описание задачи обычно уже есть в тикете или на странице Wiki\u002FConfluence, поэтому в \u002Fopsx:propose мне достаточно указать ссылку. Поскольку мой агент подключён к этим корпоративным системам, он сам загрузит исходные требования и уже на их основе создаст изменение (change).\n\nВ рамках propose агент сначала смотрит, что уже зафиксировано в main specs. Если спецификации есть, он определяет, какие из них затронет изменение: какие требования нужно добавить, какие — уточнить, а какие — убрать. Если main specs ещё нет — как в нашем чистом Spring Boot-проекте, — агент описывает новое поведение с нуля. Результат этой работы — delta specs: требования и сценарии, описывающие только разницу между текущим и желаемым поведением системы.\n\nЗатем агент разбирает текущую кодовую базу: какие модули и зависимости уже есть, куда логично встроить новую функциональность и какие технические ограничения нельзя игнорировать. На этой основе он готовит [design.md](http:\u002F\u002Fdesign.md) — технический дизайн изменения — и [tasks.md](http:\u002F\u002Ftasks.md) — план работ, по которому агент будет реализовывать задачу на следующем шаге.\n\n![OpenSpec propose skill actions]({{strapiUrl}}\u002Fuploads\u002F7e408b1f1ab33e8ad52738dbe5a7e08c_86a55e7168.webp)\n\nКогда propose завершится, проверяем сгенерированные артефакты. Я читаю их в таком порядке: [proposal.md](http:\u002F\u002Fproposal.md) → specs → [design.md](http:\u002F\u002Fdesign.md) → [tasks.md](http:\u002F\u002Ftasks.md). Нужно убедиться, что агент верно понял исходную задачу и что предлагаемая реализация соответствует нашим ожиданиям: по интерфейсу, пользовательским сценариям и внутренней архитектуре. В [tasks.md](http:\u002F\u002Ftasks.md) отдельно проверяю, что в плане есть задачи, связанные с проверкой барьеров (guardrails): юнит- и интеграционные тесты, Checkstyle, архитектурные проверки ArchUnit, coverage и мутационное тестирование PITest. Кроме того, убеждаюсь, что есть задача на ревью кода другим агентом: если основную разработку вёл Claude Code, ревью делает Codex, и наоборот.\n\nВ моей ситуации мне часто приходилось просить агента вносить одни и те же правки от изменения к изменению на этапе propose. Снизить количество правок и скорректировать поведение агента можно несколькими способами:\n\n1. Добавить «управляющий» prompt в [CLAUDE.md](http:\u002F\u002FCLAUDE.md) или [AGENTS.md](http:\u002F\u002FAGENTS.md) вашего агента\n2. Положить инструкции в openspec\u002F[AGENTS.md](http:\u002F\u002FAGENTS.md) — OpenSpec сам поддерживает этот файл\n3. Описать правила в конфигурационном файле OpenSpec — openspec\u002Fconfig.yaml\n4. Создать собственную схему артефактов\n\nАртефакты проверены, правки зафиксированы — можно переходить к непосредственной реализации.\n\n#### Apply\n\nЧтобы агент начал разрабатывать спецификацию, достаточно вызвать \u002Fopsx:apply. Он возьмёт [tasks.md](http:\u002F\u002Ftasks.md) выбранного изменения и пойдёт по пунктам плана. Но перед этим я делаю несколько предварительных шагов.\n\nСначала коммичу change-спецификацию. На этом этапе в репозитории ещё нет кода фичи — только proposal, delta specs, design и tasks. Если во время реализации что-то пойдёт не так, к согласованным артефактам всегда можно вернуться.\n\nДальше создаю отдельный worktree и веду в нём всю разработку. Так текущая реализация не пересекается с другими незавершёнными изменениями, а при необходимости разработку нескольких спецификаций можно вести параллельно.\n\nЗатем очищаю контекст текущей сессии или завожу новую. Сессия propose уже успела обрасти обсуждением, комментариями и промежуточными правками, а для реализации агенту это не нужно и может быть даже вредно: всё необходимое уже лежит в файлах изменения (change).\n\n![Подготовка к запуску opsx apply]({{strapiUrl}}\u002Fuploads\u002Fff6626db14ef192221cb0a0a445a0578_df78be8c2c.webp)\n\nПосле этого вызываю \u002Fopsx:apply уже с указанием конкретной change-спецификации.\n\n```\n\u002Fopsx:apply add-vets-crud-api\n```\n\n![Запуск opsx apply в OpenIDE]({{strapiUrl}}\u002Fuploads\u002Fb39b862ed70beaa88099271ed278570a_85f2229d9b.webp)\n\nНа этом этапе агент уже не планирует, а пишет код. OpenSpec задаёт, _что_ нужно сделать, но не заменяет инструкции о том, _как_ это делать в Spring. Поэтому [Spring Skills](https:\u002F\u002Fgithub.com\u002FAmplicode\u002Fspring-skills) сохраняют свою актуальность: агент по-прежнему опирается на них, когда создаёт сущности, репозитории, DTO и REST-контроллеры.\n\nПосле того как код написан, необходимо сделать его ревью. Агент генерирует слишком много изменений, чтобы читать каждое одинаково внимательно, поэтому смотрю только наиболее значимый код: модель, сервисы, репозитории, db-миграции и тесты.\n\nОбязательно проверяю наличие автоматизированных end-to-end-тестов и их корректность. Если автоматизировать некоторые end-to-end-сценарии по какой-то причине невозможно, прохожу их руками (или прошу пройти QA). Затем запускаю PITest для вновь написанного или изменённого кода, чтобы убедиться, что на этапе разработки агент не упустил какой-нибудь из важных сценариев.\n\nЗакончив ревью и все необходимые проверки, хочется сразу закоммитить изменения, создать PR\u002FMR и двинуться по стандартному процессу. Но постойте, постойте: мы ещё не превратили delta спецификации в main спецификации. Поэтому изменения в исходном коде коммитим, а PR\u002FMR пока не создаём. Сначала нужно выполнить синхронизацию спецификаций и архивацию изменения.\n\n#### Sync & Archive\n\nЗачем вообще синхронизировать спецификации? Пока delta спецификации живут только внутри изменения (change), main спецификации по-прежнему описывают систему _до_ нашей доработки. А ведь именно main спецификации — источник истины, на который агент будет опираться в следующих propose. Если их не обновить, следующее изменение начнётся с устаревшей картины мира: агент не увидит уже добавленные требования и либо опишет их заново, либо спокойно предложит поведение, которое мы только что реализовали иначе. Синхронизация переносит ADDED, MODIFIED и REMOVED из delta спецификаций в main спецификации. Для этого в OpenSpec есть специальная команда \u002Fopsx:sync. Но не торопитесь её вызывать.\n\nДело в том, что синхронизация — только половина работы. Пока изменение лежит в changes\u002F, OpenSpec считает его незавершённым. Чтобы завершить изменение (change), его необходимо заархивировать. Для этого в OpenSpec есть команда \u002Fopsx:archive.\n\n![Синхронизация и архивация изменения OpenSpec]({{strapiUrl}}\u002Fuploads\u002Fdeb04209b37954fe2d3f7ec626242af2_007cf98aac.webp)\n\nВ процессе архивации агент, во-первых, выполняет синхронизацию delta спецификаций с main спецификациями, а во-вторых, переносит каталог изменения (change) в changes\u002Farchive\u002F с текущей датой. Proposal, design, tasks и delta спецификации, а также другие артефакты никуда не пропадают: к ним всегда можно будет вернуться позже.\n\nТак же, как и перед apply, я очищаю текущую сессию или завожу новую и вызываю \u002Fopsx:archive с указанием названия изменения.\n\n```\n\u002Fopsx:archive add-vets-crud-api\n```\n\n![Запуск opsx archive в OpenIDE]({{strapiUrl}}\u002Fuploads\u002F71fdd66fd8ddc04f8ff32569c02e733a_fee51fb29f.webp)\n\nКоммитим результаты синхронизации и архивации, создаём PR\u002FMR, выполняем остальные шаги стандартного процесса разработки и переходим к следующей задаче, начиная с шага propose. Таким образом мы прошли полный цикл внесения изменения с OpenSpec.\n\n\u003Ch2 id=\"zaklyuchenie\">Заключение\u003C\u002Fh2>\n\nТеперь мы знаем всё необходимое, чтобы начать вести разработку с OpenSpec: как устроены требования и спецификации, чем main specs отличаются от delta specs и как изменение проходит через этапы Propose, Apply и Archive.\n\nЧтобы попробовать SDD и OpenSpec в частности, не нужно начинать новый проект: подключить OpenSpec можно в любой момент жизненного цикла приложения. Возьмите одну небольшую фичу с понятными границами и пройдите пройти полный цикл внесения изменений.\n\n![]({{strapiUrl}}\u002Fuploads\u002Fe99a21058d9d0f677cf8e03c8f8a0103_43e3ea1907.webp)\n\n[OpenIDE](https:\u002F\u002Fopenide.ru\u002F) бесплатна навсегда, а Pro версию [можно попробовать](https:\u002F\u002Fopenide.ru\u002Fdownload) в течение 60 дней без регистрации. Часть описанных возможностей доступна и в обычной версии, все возможности без исключения в OpenIDE Pro.\n\n---\n\n_Впервые опубликовано на [Хабре](https:\u002F\u002Fhabr.com\u002Fru\u002Fcompanies\u002Fhaulmont\u002Farticles\u002F1085536\u002F)._\n",[20],{"title":21,"links":22},"Содержание",[23,26,29,32],{"label":24,"href":25},"Немного теории","#nemnogo-teorii",{"label":27,"href":28},"OpenSpec","#openspec",{"label":30,"href":31},"OpenSpec Change","#openspec-change",{"label":33,"href":34},"Заключение","#zaklyuchenie","2026-11-12T11:23:59.064Z","2026-11-13T11:49:15.279Z","2026-11-13T11:49:15.352Z",{"id":39,"documentId":40,"firstname":41,"lastname":42,"createdAt":43,"updatedAt":43,"publishedAt":44,"slug":45,"photo":46},32,"o6vt7fwz9hd363ulcgbilr84","Илья","Кучмин","2026-11-12T11:20:31.602Z","2026-11-12T11:20:50.815Z","ilya-kuchmin",null,{"id":48,"documentId":49,"name":50,"alternativeText":46,"caption":46,"width":51,"height":52,"formats":53,"hash":79,"ext":57,"mime":58,"size":80,"url":81,"previewUrl":46,"provider":82,"provider_metadata":46,"createdAt":83,"updatedAt":83,"publishedAt":84,"focalPoint":46},1199,"c4y54rmc0r1in0aa4dpvy5z7","cover-chto-takoe-openspec-polnyj-gajd-po-spec-driven-development.webp",1000,666,{"thumbnail":54,"medium":64,"small":72},{"name":55,"hash":56,"ext":57,"mime":58,"path":46,"width":59,"height":60,"size":61,"sizeInBytes":62,"url":63},"thumbnail_cover-chto-takoe-openspec-polnyj-gajd-po-spec-driven-development.webp","thumbnail_cover_chto_takoe_openspec_polnyj_gajd_po_spec_driven_development_2bc278b06a",".webp","image\u002Fwebp",234,156,7.75,7748,"\u002Fuploads\u002Fthumbnail_cover_chto_takoe_openspec_polnyj_gajd_po_spec_driven_development_2bc278b06a.webp",{"name":65,"hash":66,"ext":57,"mime":58,"path":46,"width":67,"height":68,"size":69,"sizeInBytes":70,"url":71},"medium_cover-chto-takoe-openspec-polnyj-gajd-po-spec-driven-development.webp","medium_cover_chto_takoe_openspec_polnyj_gajd_po_spec_driven_development_2bc278b06a",750,500,35.31,35306,"\u002Fuploads\u002Fmedium_cover_chto_takoe_openspec_polnyj_gajd_po_spec_driven_development_2bc278b06a.webp",{"name":73,"hash":74,"ext":57,"mime":58,"path":46,"width":68,"height":75,"size":76,"sizeInBytes":77,"url":78},"small_cover-chto-takoe-openspec-polnyj-gajd-po-spec-driven-development.webp","small_cover_chto_takoe_openspec_polnyj_gajd_po_spec_driven_development_2bc278b06a",333,22.05,22046,"\u002Fuploads\u002Fsmall_cover_chto_takoe_openspec_polnyj_gajd_po_spec_driven_development_2bc278b06a.webp","cover_chto_takoe_openspec_polnyj_gajd_po_spec_driven_development_2bc278b06a",56.32,"\u002Fuploads\u002Fcover_chto_takoe_openspec_polnyj_gajd_po_spec_driven_development_2bc278b06a.webp","local","2026-11-13T11:43:34.388Z","2026-11-13T11:43:34.389Z",[86],{"id":87,"documentId":88,"title":89,"published":90,"weight":91,"slug":92,"createdAt":93,"updatedAt":94,"publishedAt":95,"color":46},4,"ap54riuwcv7sj63auhmb4i6d","Гайды",true,3,"guides","2026-11-12T11:20:31.298Z","2026-11-12T11:22:44.141Z","2026-11-12T11:22:44.122Z",{"pagination":97},{"page":98,"pageSize":99,"pageCount":98,"total":98},1,25,{"data":101,"meta":120},[102,108,114],{"published_date":103,"id":104,"documentId":105,"title":106,"slug":107},"2026-09-10",326,"ymtfa6pslevvkrwnohdfbi1u","Как не потерять интеграцию с Docker в IDE после блокировки JetBrains","kak-ne-poteryat-integracziyu-s-docker-v-ide-posle-blokirovki-jetbrains",{"published_date":109,"id":110,"documentId":111,"title":112,"slug":113},"2026-09-01",400,"dskd9jsck2vjm1d0ztoz91uo","JavaScript и TypeScript в OpenIDE: Node.js, React, Angular, Git и работа с API","javascript-i-typescript-v-openide",{"published_date":115,"id":116,"documentId":117,"title":118,"slug":119},"2026-08-06",363,"x62phzooqpahmwnv33cijbmm","DB-клиент OpenIDE: от подключения к базе до EXPLAIN и экспорта данных","db-klient-openide-ot-podklyucheniya-k-baze-do-explain-i-eksporta",{"pagination":121},{"page":98,"pageSize":91,"pageCount":122,"total":123},6,16,1794584598483]