[{"content":"","date":"11 августа 2026","externalUrl":null,"permalink":"/posts/","section":"","summary":"","title":"","type":"posts"},{"content":"","date":"11 августа 2026","externalUrl":null,"permalink":"/authors/","section":"Authors","summary":"","title":"Authors","type":"authors"},{"content":"","date":"11 августа 2026","externalUrl":null,"permalink":"/categories/","section":"Categories","summary":"","title":"Categories","type":"categories"},{"content":"","date":"11 августа 2026","externalUrl":null,"permalink":"/tags/contributing/","section":"Tags","summary":"","title":"Contributing","type":"tags"},{"content":"","date":"11 августа 2026","externalUrl":null,"permalink":"/authors/default/","section":"Authors","summary":"","title":"Default","type":"authors"},{"content":"","date":"11 августа 2026","externalUrl":null,"permalink":"/categories/development/","section":"Categories","summary":"","title":"Development","type":"categories"},{"content":"","date":"11 августа 2026","externalUrl":null,"permalink":"/tags/development/","section":"Tags","summary":"","title":"Development","type":"tags"},{"content":"","date":"11 августа 2026","externalUrl":null,"permalink":"/tags/github/","section":"Tags","summary":"","title":"Github","type":"tags"},{"content":"","date":"11 августа 2026","externalUrl":null,"permalink":"/","section":"Home","summary":"","title":"Home","type":"page"},{"content":"","date":"11 августа 2026","externalUrl":null,"permalink":"/categories/metaform/","section":"Categories","summary":"","title":"Metaform","type":"categories"},{"content":"","date":"11 августа 2026","externalUrl":null,"permalink":"/tags/metaform/","section":"Tags","summary":"","title":"Metaform","type":"tags"},{"content":"","date":"11 августа 2026","externalUrl":null,"permalink":"/categories/open-source/","section":"Categories","summary":"","title":"Open Source","type":"categories"},{"content":"","date":"11 августа 2026","externalUrl":null,"permalink":"/tags/open_source/","section":"Tags","summary":"","title":"Open_source","type":"tags"},{"content":"","date":"11 августа 2026","externalUrl":null,"permalink":"/tags/","section":"Tags","summary":"","title":"Tags","type":"tags"},{"content":"","date":"11 августа 2026","externalUrl":null,"permalink":"/tags/translate/","section":"Tags","summary":"","title":"Translate","type":"tags"},{"content":" Благодарим за проявленный интерес к проекту # Спасибо за желание сделать Metaform лучше! В этом документе описаны правила и процесс внесения изменений в проект. Этот файл поможет вам разобраться в процессе внесения вклада в проект, от первых шагов до pull request.\nОрганизация ветвей # ⚠️ Важно: до выпуска версии 2.0 ветка main не отражает текущую опубликованную в npm версию. Это временное исключение связано с подготовкой релиза 2.0. После выпуска 2.0 данное уведомление будет удалено, а main и develop будут работать по правилам, описанным ниже.\n⚠️ Все изменения вносите в ветку develop. Эта ветка предназначена для текущей разработки и может содержать как новые возможности, так и изменения, которые ещё не вошли в релиз.\n⚠️ Изменения из develop попадают в main только при подготовке нового релиза. Поэтому main не должна содержать изменений, нарушающих обратную совместимость с текущей версией latest.\n⚠️ Финальная версия публикуется автоматически из ветки main — за это отвечает maintainer. Изменения в CHANGELOG.md и настройки инструментов сборки вносит только maintainer, за исключением заранее оговорённых случаев.\nКратко\nЭти правила полноценно вступают в силу после полноценного релиза v2.0.0 develop — вся текущая разработка и новые изменения. main — последняя стабильная версия, опубликованная в npm. main должна оставаться обратно совместимой с текущим latest. Финальная версия публикуется автоматически из ветки main, за это отвечает maintainer, изменения CHANGELOG.md настройки инструментов сборки меняет только maintainer, за исключением заранее оговоренных случаев. Breaking changes требуют изменения версии перед попаданием в main. Семантическое версирование # Metaform следует принципам семантического управления версиями. Мы выпускаем исправляющие версии (patch) для устранения ошибок, минорные (minor) — для добавления новых возможностей, и мажорные (major) — для изменений, нарушающих обратную совместимость.\nПолучение кода Metaform и настройка окружения # Требования к платформе # Nodejs (версии 24.0.0^ или выше) Пакетный менеджер: pnpm (11.20.0 или выше) Клонирование проекта и установка зависимостей # # Получение репозитория git clone https://github.com/maxqwars/metaform.git cd metaform/ # Обновление данных git fetch origin # Переход на ветку develop git checkout develop # Установка зависимостей pnpm install Список скриптов # pnpm dev — запуск сборщика в режиме отслеживания изменений (watch mode). pnpm test — запуск модульных тестов с помощью Vitest. pnpm test:coverage — проверка покрытия кода тестами. pnpm typecheck — проверка типов TypeScript. pnpm lint — проверка кода линтером. pnpm format — автоматическое форматирование кода через Prettier. 💡 Архитектура и структура кода: Перед тем как писать код или добавлять новые эндпоинты, обязательно ознакомьтесь с Архитектурным руководством (ARCHITECTURE.md). В нём подробно описаны структура файлов, паттерны DTO/Guards и чек-лист добавления нового API.\nСтандарты кода и правила коммитов # Мы используем Husky и lint-staged для проверки форматирования перед коммитом, а также следуем стандарту Conventional Commits:\n\u0026lt;тип\u0026gt;(\u0026lt;область\u0026gt;): \u0026lt;краткое описание\u0026gt;\nПопулярные типы:\nfeat: — новая функциональность fix: — исправление ошибки docs: — изменения в документации refactor: — переписывание кода без изменения внешнего API test: — добавление или исправление тестов Пример: fix(core): resolve null pointer in user parsing\nОформление PR (Pull Request) запросов # Убедитесь, что ваш PR направлен в ветку develop. В описании PR укажите, какую проблему решает данный PR (ссылка на Issue: Fixes #123). Не обновляйте версию в package.json и CHANGELOG.md — это делается централизованно при выпуске релиза. Перед отправкой убедитесь, что все проверки (pnpm typecheck, pnpm test, pnpm lint) проходят успешно. Ищете, с чего начать? # Если вы хотите внести свой первый вклад в Metaform, но не знаете, какую задачу выбрать:\nНайдите подходящий Issue: Зайдите во вкладку Issues и отфильтруйте задачи по меткам (labels): good first issue — небольшие изолированные задачи, идеальные для первого знакомства с кодовой базой. help wanted — задачи, в которых проекту особенно нужна помощь сообщества. Забронируйте задачу: Напишите комментарий в выбранном Issue (например, \u0026ldquo;I\u0026rsquo;d like to work on this!\u0026rdquo;), чтобы мы закрепили его за вами. Это поможет избежать ситуаций, когда несколько человек параллельно делают одну и ту же работу. Свяжите PR с задачей: При создании Pull Request укажите ссылку на проблему в описании (Fixes #123 или Closes #123), чтобы Issue автоматически закрылся после мёрджа. Предложения и не-кодовый вклад # Вам не обязательно писать код, чтобы помочь проекту! Мы ценим любые идеи, обратную связь и улучшение документации.\nПредложение нового функционала (Feature Request) # Если у вас есть идея новой возможности или предложения по улучшению API Metaform:\nПроверьте существующие Issues, чтобы убедиться, что идея ещё не обсуждается. Создайте новый Issue с типом Feature Request. В описании постарайтесь указать: Проблему / Use Case: Зачем нужна эта фича? Какую реальную задачу она решает? Предлагаемое решение: Как, по вашему мнению, должен выглядеть API или поведение библиотеки? Альтернативы: Рассматривали ли вы другие способы решения этой задачи? Улучшение документации # Нашли опечатку, неточность в описании типов или неработающий пример кода в README/документации?\nДля мелких правок (опечатки, форматирование) можно сразу создавать Pull Request в ветку develop. Для крупных изменений лучше предварительно создать Issue и обсудить структуру. Ошибки: сообщение и исправление # Как сообщить о новой ошибке # Перед созданием темы в GitHub Issues:\nПроверьте дубликаты: Убедитесь через поиск, что баг ещё не описан. Если похожий Issue уже есть, дополните его своими деталями. Проверьте версию: Убедитесь, что проблема воспроизводится на последней версии Metaform. Подготовьте MRE: Предоставьте минимальный воспроизводимый пример (Minimal Reproducible Example). Укажите контекст: Краткое описание проблемы; Ожидаемое и фактическое поведение; Минимальный код или конфигурация; Версии Metaform, Node.js и среда выполнения и ее версия (если не используете Node.js) Как предложить исправление зарегистрированной ошибки # Если вы нашли открытый Issue с багом и хотите его исправить:\nЗабронируйте задачу: Напишите в комментариях к Issue, что берёте его в работу («I\u0026rsquo;d like to work on a fix for this!»), чтобы избежать дублирования работы с другими контрибуторами. Свяжите PR с проблемой: В описании Pull Request укажите ссылку на Issue (Fixes #123 или Closes #123), чтобы он автоматически закрылся при мёрдже. Добавьте регрессионный тест: К исправлению обязательно должен прилагаться тест в папке __tests__/. Он должен падать без вашего кода и успешно проходить с ним. Фокусируйтесь на главном: Не добавляйте в PR сторонний рефакторинг, форматирование чужого кода или новые фичи. Сохраняйте обратную совместимость: Исправление не должно ломать публичный API или текущее поведение библиотеки. 💡 Что такое регрессионный тест и как его написать? # Это не отдельная система тестирования, а обычный юнит-тест Vitest. Вы просто добавляете новый it(...) в существующий файл тестов в папке __tests__/ рядом с исправляемым файлом.\nНапишите тест, воспроизводящий сценарий из Issue (без ваших правок он должен падать). Внесите исправление в исходный код, чтобы тест стал успешным (pnpm test). Отправьте файл с новым тестом и ваш багфикс в одном Pull Request. Обратите внимание: делать всё одним коммитом не обязательно. Отличная практика — сначала сделать коммит с падающим тестом (демонстрирующим ошибку), а следующим коммитом добавить исправление, делающее тест «зеленым».\nЗоны ответственности # Что бы объяснить и разделить, кто формирует релиз, кто управляет окружением, принимает решения по какому пути идет развитие библиотеки, считаем необходимым объяснить зоны ответственности.\nМейнтейнер (Maintainer) # Отвечает за обслуживание кода, поддержание стабильности веток, принятие решений по Pull Request (Merge / Reject) и запуск релизов. Мейнтейнер контролирует кодовую базу целиком — от конфигурации инструментов и версий зависимостей до ревью стороннего кода.\nКонтрибутор (Contributor) # Добровольный разработчик, помогающий в развитии Metaform. Вы можете отправлять исправления кода, предлагать новые фичи, находить ошибки и улучшать документацию.\n⚠️ Архитектурные и инфраструктурные изменения:\nСторонние разработчики могут предлагать улучшения архитектуры, инструментов или крупных зависимостей. Однако любые изменения, существенно влияющие на Metaform и её пользователей, должны предварительно обсуждаться в отдельном Issue, чтобы исключить неприятные побочные эффекты и избежать бесполезно потраченного времени на PR.\nБезопасность (Security Policy) # Если вы обнаружили потенциальную уязвимость безопасности в Metaform, пожалуйста, не создавайте публичный Issue.\nИспользуйте приватный механизм GitHub Security Advisories или свяжитесь с мейнтейнером напрямую, чтобы мы могли оперативно подготовить патч до разглашения информации.\nЛицензия и авторство (License \u0026amp; Recognition) # Лицензия MIT: Metaform распространяется под лицензией MIT. Согласие с лицензией: Отправляя Pull Request, вы подтверждаете, что ваш вклад будет опубликован на условиях лицензии MIT. Признание авторов: Ваше имя (или никнейм GitHub) будет добавлено в файл CONTRIBUTORS в знак благодарности за помощь проекту. ","date":"11 августа 2026","externalUrl":null,"permalink":"/posts/metaform-contributing-guide/","section":"","summary":"","title":"Перевод руководства для контрибюторов Metaform","type":"posts"},{"content":"","date":"8 августа 2026","externalUrl":null,"permalink":"/tags/ai/","section":"Tags","summary":"","title":"Ai","type":"tags"},{"content":"","date":"8 августа 2026","externalUrl":null,"permalink":"/categories/ai/","section":"Categories","summary":"","title":"AI","type":"categories"},{"content":"","date":"8 августа 2026","externalUrl":null,"permalink":"/tags/continue/","section":"Tags","summary":"","title":"Continue","type":"tags"},{"content":"","date":"8 августа 2026","externalUrl":null,"permalink":"/tags/lm_studio/","section":"Tags","summary":"","title":"Lm_studio","type":"tags"},{"content":"","date":"8 августа 2026","externalUrl":null,"permalink":"/tags/ollama/","section":"Tags","summary":"","title":"Ollama","type":"tags"},{"content":"","date":"8 августа 2026","externalUrl":null,"permalink":"/categories/tools/","section":"Categories","summary":"","title":"Tools","type":"categories"},{"content":"","date":"8 августа 2026","externalUrl":null,"permalink":"/tags/vs_code/","section":"Tags","summary":"","title":"Vs_code","type":"tags"},{"content":"","date":"8 августа 2026","externalUrl":null,"permalink":"/tags/workflow/","section":"Tags","summary":"","title":"Workflow","type":"tags"},{"content":" TR;DR # Я отличаю AI-assisted development от vibecoding — модель усиливает мышление, а не заменяет его. Мой рабочий стек — VS Code + Continue + LM Studio с локальными моделями, без завязки на облако. В статье — набор промтов, которые реально использую (коммиты, тесты на Vitest, объяснение TODO/README), с честной оценкой, где справляется маленькая 8B-модель, а где нет. Отдельно — про то, почему Continue после 2.0 всё сильнее тянет в сторону обязательного облачного Hub и что с этим делать, если тебе важен Local-First подход.\nКак я пришел к ИИ # Долгое время я относился к нейросетям исключительно как к редакторскому инструменту. На прежнем месте работы — в фонде при ЦИБМ — я использовал ИИ в основном для автоматизации рутины: суммировал новости из сферы информационной безопасности и пересобирал их в посты нужного формата. Мне казалось, что на большее современные модели не способны, а для задач реального программирования они банально не созрели. Однако с развитием локальных моделей и ассистентов подход пришлось пересмотреть: ИИ действительно становится неотъемлемой частью разработки, хотя и совсем не так, как это представляют себе сторонники хайпа.\nAI-Assisted != Vibecoding # Из-за популярности определения vibecoding считаю нужным внести ясность в различие между программированием силами чат моделей и программированием с ассистированием. Определение \u0026ldquo;вайбкодер\u0026rdquo; фрустрирует нормальных разработчиков, из-за мнения что разработчик использующий ИИ, это обязательно вайбкодер, который самостоятельно ничего не может, и многие забывают о том, что разработка это не только написание кода но и множество процессов построенных вокруг него.\nРазличия двух подходов # Vibecoding # Это когда в основном отдают управление модели:\nПишут абстрактный промт, зачастую без конкретики и требований к конечной реализации Принимают почти все что навыдумывала им модель Минимальное чтение и понимание выдуманного кода Удовлетворённость от того что код хотя бы примерно делает то что нужно Не могут объяснить код, почему он такой и как он работает AI-Assisted development # Это когда AI — инструмент, а не замена мышлению:\nЧеткое понимание задачи и архитектуры Модели дается четкий и ограниченный задачей контекст Критическое отношение к генерированному коду, обязательная правка при необходимости Право проектирования архитектуры, именований, обработку ошибок разработчик оставляет за собой, выстраивается граница ответственности AI используется для ускорения рутины, исследование, суммирование сделанных изменений и тд. Нет мысли и желания чтобы модель сделала всё за разработчика Если объяснить разницу одной строкой # AI-Assisted development — это когда ты усиливаешь своё мышление с помощью модели. Vibecoding — это когда ты делегируешь мышление модели и надеешься на лучшее.\nОт чата к агенту # Из-за своего редакторского опыта в фонде я долгое время откладывал выяснение, что там за хайп по агентам и что такое этот ваш новый протокол контекста. То есть моя работа была банальной: берём чат-интерфейс и ручками копируем текст, формируя контекст. Сильно позже, углубившись в тему и попробовав Prisma MCP и daisyUI MCP, я осознал, насколько ограниченно применял ИИ.\nРазница между этими вариантами взаимодействия ощутима:\nОбычный режим чата — это работа с «изолированным окружением». Модель знает только то, что ты физически вставил в промт. У неё нет доступа к твоему проекту, структуре файлов, терминалу или документации.\nАгентный режим (Agentic Mode) — это подход, при котором модель перестаёт быть просто генератором текста и становится активным участником процесса. Агент сам определяет цепочку шагов для решения задачи: может исследовать дерево проекта, прочитать нужные файлы, внести правки, запустить тесты в терминале и исправить свои же ошибки по результатам их выполнения.\nMCP (Model Context Protocol) — это открытый стандарт от Anthropic, который работает как «универсальный переходник» для инструментов доступных ИИ. С его помощью модель может безопасно подключаться к внешним источникам данных и инструментам: локальным базам данных, API GitHub, файловой системе, документации или системам логирования, не требуя написания уникального кода под каждый сервис.\nОсознав, насколько агентный режим и интеграция контекста ускоряют работу, я захотел перенести этот опыт прямо в рабочий редактор. И начать я решил с локального сетапа, который позволил бы мне опробовать такую интеграцию.\nМой стек: VS Code + Continue + LM Studio # Visual Studio Code # Visual Studio Code — мой основной редактор кода уже много лет. В своё время он пришёл на смену Sublime Text благодаря огромной экосистеме расширений. Не вижу смысла спорить о «лучшем редакторе», просто зафиксируем факт: любые AI-инструменты я искал с привязкой к привычной среде разработки.\nContinue # Сами авторы позиционируют Continue как новаторский программный агент с открытым исходным кодом (Pioneering open-source coding agent).\nVisualStudio Marketplace github.com/continuedev/continue Именно это расширение я выбрал для интеграции моделей в свой рабочий процесс. Continue добавляет:\nВстроенный чат прямо в боковой панели; Быстрые комбинации клавиш (шорткаты) для выделения кода и моментальной отправки его в контекст; Возможность кастомизации: можно создавать собственные промты и вызывать их через /prompt-id. Но главное преимущество Continue перед обособленными консольными утилитами (вроде Gemini CLI) — он отлично дружит с локально развёрнутыми моделями и (или) не навязывает использование облачных или огромных моделей уровня 30B параметров и более, неспособных запуститься на потребительском железе*.\nСноска про OpenCode: Небольшое лирическое отступление. Я честно пытался завести OpenCode, но так и не смог заставить его адекватно работать с моделями меньше 30B параметров — он почему-то упорно игнорировал мой конфиг с переопределением моделей. Но если ситуация с Continue продолжится в сторону облака, не исключаю, что перейду именно на него.\nКакие режимы поддерживает Continue # Chat — привычный диалоговый интерфейс в панели VS Code. Подходит для быстрых вопросов, генерации функций по описанию или объяснения отдельных кусков кода. Plan (Планирование) — режим, в котором модель сначала изучает контекст проекта и строит пошаговый план решения задачи (архитектурный план). Ты проверяешь его, вносишь правки и только потом отдаёшь команду на исполнение. Это отличный предохранитель от хаотичных правок (правда, из-за аппаратных ограничений на размер моделей я его почти не использую). Agent (Агентный режим) — полноценное исполнение. В этом режиме модель получает возможность исследовать дерево проекта, читать файлы, выполнять команды в терминале и задействовать сторонние MCP-серверы для работы с внешними инструментами. LM Studio # В качестве локального бэкенда (инференс-движка) я использую LM Studio. Это удобное GUI-приложение, которое позволяет в пару кликов скачивать квантованные GGUF-модели с Hugging Face, гибко настраивать распределение слоёв на VRAM/RAM и поднимать локальный сервер, полностью совместимый с OpenAI API (http://localhost:1234/v1).\n🤖 Промты которые я использую # Здесь я оставляю небольшой список промтов которые использую во время написания кода, при обслуживании кода или когда ищю новые проекты, я надеюсь они будут вам полезны.\nПоскольку я использую локальные модели, а они на потребительском оборудовании работают с ограниченным числом параметров, по каждому промту будет сноска как эффективно они работают на моделях с 8B параметров, и это опыт для модели Gemma4.\nОформление коммитов по Angular Commit Convention # Сноска: На малой модели работает хорошо\n📋 Показать системный промт Convert the following Russian description into an English commit message using the Angular Commit Convention. Rules: - Use one of the following types: - feat: new feature - fix: bug fix - docs: documentation changes - style: formatting, whitespace, linting - refactor: code refactoring without behavior changes - perf: performance improvements - test: adding or updating tests - build: build system or dependencies - ci: CI/CD changes - chore: maintenance tasks - revert: reverting previous changes - Format: \u0026lt;type\u0026gt;(\u0026lt;scope\u0026gt;): \u0026lt;short description\u0026gt; - Subject: - English only - imperative mood - lowercase - no period at the end - maximum 72 characters - Scope: - infer from the description when possible - examples: auth, api, ui, users, payments, config - If multiple changes are present, add a blank line and a bullet list. Examples: Russian: Добавил авторизацию через OAuth2 Result: feat(auth): add oauth2 authentication Russian: Исправил обновление токена и добавил тесты Result: fix(auth): handle token refresh correctly - add integration tests for refresh flow Return only the commit message. Обьяснение кода # Сноска: На малой модели работает хорошо на малом коде или отдельной функции, на большой кодовой базе работает хуже.\n📋 Показать содержимое промта Объясни на русском языке, что делает выделенный код. Структура ответа: - Назначение: для чего этот код нужен, какую задачу решает - Как работает: пошаговое объяснение логики простыми словами - Входные данные: что принимает функция/модуль (параметры, типы) - Выходные данные: что возвращает и в каком формате - Особенности: побочные эффекты, мутации, асинхронность, обработка ошибок (если есть) - Возможные проблемы: на что стоит обратить внимание (если есть) Объясняй так, как будто рассказываешь коллеге, который видит этот код впервые. Избегай простого пересказа кода построчно — фокусируйся на смысле и логике. Генерация юнит тестов с Vitest # Сноска: На малой модели работает хорошо, для геренации простых тестов подходит, но зачастую не хватает информации о типах или конфигурации TypeScript, может использовать vi.mock, но использует его и в тех местах где он не нужен.\n📋 Показать содержимое промта Write comprehensive unit tests for the selected TypeScript code using Vitest. Requirements: Setup: - Use `describe`/`it` blocks, grouped logically by function/method/class. - Import everything with correct relative paths and types. - Use `vi.fn()`, `vi.mock()`, `vi.spyOn()` for mocking dependencies, external modules, timers, and Date where relevant. - Strictly type all mocks and test data — no `any`. Coverage goals (aim for 100%): - Test every exported function, method, and branch (if/else, switch, ternary, short-circuit operators, optional chaining). - Test every early return and thrown error path. - Test all loops with 0, 1, and multiple items. Edge cases to always consider: - Empty inputs: empty string, empty array, empty object, empty Map/Set. - Nullish values: `null`, `undefined`, missing optional fields. - Boundary values: 0, negative numbers, max/min safe integers, very long strings. - Invalid/malformed input (wrong types passed at runtime, malformed JSON, etc.). - Async edge cases: rejected promises, timeouts, race conditions, concurrent calls. - Idempotency: calling the function multiple times with the same input. - Side effects: verify mocked dependencies are called with correct arguments, correct number of times. Assertions: - Use precise matchers (`toEqual`, `toStrictEqual`, `toThrow`, `toHaveBeenCalledWith`, `rejects.toThrow`, etc.) — avoid loose `toBeTruthy`/`toBeFalsy` unless appropriate. - For error cases, assert both that an error is thrown/rejected AND the error message/type. Output: - Provide the full test file, ready to run. - Add a short comment above each `it` block group explaining what scenario it covers. - At the end, list any branches or lines that may still be uncovered and explain why (if any), or what additional input/mocking would be needed to cover them. If the code under test has external dependencies (DB, HTTP, filesystem, env vars), mock them explicitly and explain the mocking strategy briefly before the test code. Перевод TODO комментариев в коде # Сноска: На малой модели работает хорошо\n📋 Показать содержимое промта You are a senior software engineer writing code comments. The user will provide a Russian description of a task or issue. Your job is to translate it into English and format it as a proper inline code comment. Rules: Prefix selection — pick the most appropriate: - TODO: something that needs to be done or implemented - FIXME: broken or incorrect code that needs to be fixed - HACK: a workaround that works but is not a proper solution - NOTE: important context or explanation for future developers - WARNING: something dangerous, fragile, or easy to break - OPTIMIZE: code that works but has performance issues - DEPRECATED: code that should no longer be used Format: // \u0026lt;PREFIX\u0026gt;: \u0026lt;translated task in English\u0026gt; Translation rules: - English only, imperative mood (e.g. \u0026#34;add\u0026#34;, \u0026#34;fix\u0026#34;, \u0026#34;remove\u0026#34;, not \u0026#34;added\u0026#34; or \u0026#34;should add\u0026#34;) - Be concise — max 72 characters per line - If the task has multiple parts, split into multiple comment lines with the same prefix - Do not add any explanation or extra text — return only the formatted comment(s) Examples: Russian: нужно добавить валидацию email перед отправкой формы Result: // TODO: add email validation before form submission Russian: этот костыль работает но нужно переписать нормально после релиза Result: // HACK: temporary workaround, rewrite properly after release // TODO: refactor this after the release Russian: метод устарел, использовать новый UserService Result: // DEPRECATED: use UserService instead Russian: здесь падает если передать пустой массив Result: // FIXME: crashes when an empty array is passed Return only the comment line(s), nothing else. Поиск и обьяснение TODO комментариев # Сноска: На малой модели работает хорошо, для небольших файлов кода без сложной логики работает. На сложной логике или коде использующий фичи языка не всегда работает корректно.\n📋 Показать содержимое промта You are a senior software engineer reviewing a codebase. Scan the selected code for all inline task comments with these prefixes: TODO, FIXME, HACK, NOTE, WARNING, OPTIMIZE, DEPRECATED For each found comment: 1. Quote the original comment exactly as written 2. Explain in Russian what the task or issue is about 3. Assess priority: - 🔴 Высокий — FIXME, WARNING, crashes or security issues - 🟡 Средний — TODO, OPTIMIZE, HACK with known risk - 🟢 Низкий — NOTE, DEPRECATED, cosmetic or future improvements 4. Suggest a short action plan in Russian (1-3 steps max) Output format for each comment: --- 📌 `\u0026lt;original comment\u0026gt;` 📍 Строка: \u0026lt;line number if visible\u0026gt; 🧩 Суть: \u0026lt;explanation in Russian\u0026gt; ⚡ Приоритет: \u0026lt;🔴/🟡/🟢 + label\u0026gt; ✅ Что сделать: \u0026lt;action steps in Russian\u0026gt; --- At the end, add a short summary in Russian: - Total comments found - How many per priority level - Which one to address first and why If no task comments are found, respond: \u0026#34;В выделенном коде не найдено ни одного TODO, FIXME или аналогичного комментария.\u0026#34; Обьяснение README.md проекта # Сноска: На малой модели работает хорошо\n📋 Показать содержимое промта You are a senior software engineer helping a Russian-speaking developer understand a project. The user will provide the contents of a README.md file. Your job is to read it and explain the project in Russian in a clear, structured way. If the README is in English — translate and explain. If the README is in Russian — explain and restructure for clarity. If the README is mixed — handle each part accordingly. Output structure: ## 🧩 Что это за проект Short explanation of what the project does and what problem it solves (2-4 sentences, plain language). ## 🎯 Для кого и зачем Who is the target audience and what use cases does it cover. ## ⚙️ Технологии и зависимости List the key technologies, frameworks, and libraries mentioned. For each one briefly explain its role in the project. ## 🚀 Как запустить Step-by-step setup and launch instructions in Russian. If commands are present — keep them as-is in code blocks, translate only the surrounding explanation. ## 📁 Структура проекта If the README describes the folder/file structure — explain what each part is responsible for. ## 🔑 Ключевые возможности List the main features and capabilities of the project. ## ⚠️ Важные замечания Highlight any warnings, limitations, known issues, or prerequisites mentioned in the README. ## ❓ Что осталось непонятным If any part of the README is vague, incomplete, missing, or assumes too much prior knowledge — list it here and explain what additional context would help. Rules: - Write everything in Russian except code blocks, commands, and proper names (library names, framework names, etc.). - Do not copy-paste large chunks of the original README — explain in your own words. - If a section from the structure above is not covered in the README, skip it. - Keep the tone practical and developer-friendly — no marketing language. Обьяснение CONTRIBUTING.md # Сноска: На малой модели работает хорошо\n📋 Показать содержимое промта You are a senior software engineer helping a Russian-speaking developer understand how to contribute to a project. The user will provide the contents of a CONTRIBUTING.md file. Your job is to read it and explain the contribution guidelines in Russian in a clear, structured way. If the CONTRIBUTING.md is in English — translate and explain. If the CONTRIBUTING.md is in Russian — explain and restructure for clarity. If the CONTRIBUTING.md is mixed — handle each part accordingly. Output structure: ## 🧩 Общая идея Brief explanation of the contribution philosophy and culture of this project (2-3 sentences). ## 🚀 Как начать вносить вклад Step-by-step instructions for getting started: forking, cloning, setting up the dev environment. Keep commands as-is in code blocks, translate only the surrounding explanation. ## 🌿 Работа с ветками Branch naming conventions, what branches exist (main, dev, feature, hotfix, etc.) and how to use them. ## 📝 Как оформлять коммиты Commit message format and conventions required by this project. If Conventional Commits or similar standard is used — explain it with examples. ## 🔀 Процесс Pull Request How to open a PR: what to fill in, what checks must pass, who reviews, how long review takes. ## 🧪 Требования к тестам What tests are required before submitting. How to run them locally. ## 📐 Стандарты кода Code style, linting, formatting rules. What tools are used (ESLint, Prettier, etc.). ## 🐛 Как сообщать об ошибках How to open a bug report: what template to use, what information to include. ## 💡 Как предлагать новые функции How to propose a new feature or improvement: discussion first, issue template, RFC process if any. ## ⚠️ Важные замечания Any warnings, restrictions, legal notes (CLA, license agreements), or things that will get a PR rejected. ## ❓ Что осталось непонятным If any part of the CONTRIBUTING.md is vague, incomplete, or assumes too much prior knowledge — list it here and explain what additional context would help. Rules: - Write everything in Russian except code blocks, commands, proper names, and tool names. - Do not copy-paste large chunks of the original file — explain in your own words. - If a section from the structure above is not covered in the CONTRIBUTING.md, skip it silently. - Keep the tone practical — focus on what the developer needs to DO, not just what the file says. - If the project has unusual or strict contribution rules, highlight them clearly with ⚠️. Будущее Continue после 2.0 # Главная причина, почему я (и тысячи других разработчиков) в своё время выбрали Continue — это концепция Local-First. Ты просто открывал понятный локальный файл конфигурации (config.json, а затем сменивший его config.yaml в ~/.continue/), прописывал там endpoint локального сервера (http://localhost:1234/v1), укажи названия моделей — и всё. Никаких внешних сервисов, никакой телеметрии, никакой принудительной привязки к облачным провайдерам. Всё под твоим полным контролем.\nНо, по мере того как проект развивался в сторону агентной платформы, экосистемы Hub и утилиты CLI, в релизах наметился тревожный вектор.\nЧто меняется и почему это напрягает # Сдвиг от автономного файла к веб-платформе (Continue Hub): Если раньше config.yaml был единственным и прозрачным источником истины, то сейчас архитектуру всё сильнее смещают в сторону Continue Hub. Модели, промты, пресеты агентов и MCP-серверы предлагается забирать и выстраивать через их облачный хаб. Локальный конфиг де-факто превращается из независимого файла в клиенский слой для синхронизации с облачным профилем. Обязательная регистрация и привязка номера: Чтобы получить доступ к новым функциям, шерингу агентов и удобным интеграциям в хабе, платформа запрашивает создание аккаунта с верификацией через номер телефона. Для сообщества из РФ/СНГ это создаёт искусственные барьеры (потребуются иностранные SIM-карты или виртуальные номера), а для сторонников приватности это прямое нарушение концепции Local-First. Размытие границ Open Source: С появлением коммерческой SaaS-составляющей фокус разработки неизбежно смещается. Команда Continue вынуждена развивать сервисы подписок, команды и Cloud Hub. Для обычного инженера, использующего исключительно локальный бэкенд вроде LM Studio или Ollama, это означает риск превращения удобной утилиты в громоздкий SaaS-клиент с кучей ненужных всплывающих сервисов. И что делать дальше? # На данный момент у меня сложилось три возможных сценария дальнейшей работы:\n✅ Заморозить версию и отключить автообновления: Остаться на той версии расширения, где локальный config.yaml / config.json полностью автономен и не требует авторизации в Hub. Миграция на альтернативы (OpenCode и др.): Попробовать дожать OpenCode или переключиться на аналоги. Пусть мне пока не удалось адекватно заставить OpenCode подхватить модели меньше 30B, экосистема открытых ассистентов сейчас растёт стремительно. Если Continue станет полностью облачно-зависимым, переезд станет лишь вопросом правильной настройки CLI и IDE. Переход на комьюнити-форк: История Open Source показывает, что если популярный проект резко уходит в SaaS и ущемляет автономию пользователей, комьюнити создаёт форк, сохраняющий оригинальный Local-First подход. Выводы, тыкаем пальцем в небо # Появление способных ИИ-моделей запустило сдвиг, сравнимый с индустриальной революцией, и искусственный интеллект точно останется с нами навсегда. Мир разработки меняется, и умение работать с ИИ станет таким же усилителем продуктивности, каким в своё время стал ПК. Своей статьёй я хотел сгладить скепсис тех, кого отпугивают ошибки агентов или хайп вокруг «вайбкодинга». ИИ — это наше будущее, и от того, научимся ли мы им управлять, зависит наша дальнейшая востребованность и карьера.\n","date":"8 августа 2026","externalUrl":null,"permalink":"/posts/ai-assisted-dev/","section":"","summary":"","title":"Программирование с AI: мой текущий подход и где он уже даёт сбои","type":"posts"},{"content":"","date":"5 августа 2026","externalUrl":null,"permalink":"/categories/blog/","section":"Categories","summary":"","title":"Blog","type":"categories"},{"content":"","date":"5 августа 2026","externalUrl":null,"permalink":"/tags/lib/","section":"Tags","summary":"","title":"Lib","type":"tags"},{"content":"","date":"5 августа 2026","externalUrl":null,"permalink":"/tags/typescript/","section":"Tags","summary":"","title":"Typescript","type":"tags"},{"content":"","date":"5 августа 2026","externalUrl":null,"permalink":"/categories/typescript/","section":"Categories","summary":"","title":"TypeScript","type":"categories"},{"content":" Эволюция Metaform: Как я прошел путь от «Enterprise Java в TS» до функциональной архитектуры V2 # Эта статья — история о том, как библиотека для работы с AniLiberty API (ex. AniLibria) эволюционировала на протяжении пяти лет. Разберем архитектурные ошибки прошлого, причины отказа от «классического ООП» в JavaScript-экосистеме и то, к какому дизайну я пришел в релизе Metaform 2.0.\nИстория эволюции # 1. Ранняя реализация: xconnect и ловушка Enterprise-подхода # Первым предком библиотеки был проект xconnect (2021 год), написанный в строго объектно-ориентированном стиле.\nИз-за желания сделать «все по паттернам» проект оказался перегружен лишними абстракциями, интерфейсами и фабриками. Это был классический пример попытки применить Java/C# подходы в мире TypeScript там, где в этом не было необходимости. Репозиторий старой библиотеки maxqwars/xconnect\nГлавные проблемы xconnect:\nОгромные конструкторы и мапперы: Для перевода API-структур в доменные сущности библиотеки создавались громоздкие классы. Отсутствие валидации: Ошибки API во время выполнения никак не отлавливались и не проверялись. Избыточные абстракции: Проект плодил сущности, которые в JS легко заменяются стандартизированными встроенными модулями. Примечание: под доменными сущностями в xconnect понимались типы самой библиотеки, которые зеркально отражали API, но переводили имена полей в нотацию camelCase (например, player_team ➔ playerTeam).\n2. Переосмысление: metaform-r1 и новые грабли # Архитектура xconnect оказалась не подходящей для развития. Чтобы исправить это, была создана первая версия Metaform. Все методы API перенесли в единый монолитный класс, появился встроенный fetch с поддержкой таймаутов, а для Node.js добавился cross-fetch.\nОднако первый релиз Metaform принес свои критические баги:\nГонка запросов (Race Condition): Из-за использования одного экземпляра fetch внутри монолитного класса параллельные вызовы API перезаписывали состояние друг друга. В итоге вызванный метод мог вернуть данные совершенно другого запроса. Невалидный URL при пустом query: Билдер параметров не учитывал передачу пустого объекта {}. В результате на сервер уходил URL с некрасивым висящим знаком вопроса на конце (/api/v1/teams?). Падение login() в браузерах: Метод пытался читать куки через response.headers.get(\u0026quot;set-cookie\u0026quot;). В Node.js это работало, но браузерная политика безопасности (CORS / Forbidden response header name) строго запрещает доступ к Set-Cookie из JS-кода. Отсутствие экранирования в object2query: Сборка query-строки использовала наивную интерполяцию ${key}=${obj[key]} без encodeURIComponent. Кириллица или спецсимволы в поиске мгновенно ломали HTTP-запрос. Все эти проблемы, а также сложность добавления поддержки новых версий API, определили необходимость фундаментальных изменений.\nНовый релиз: Архитектура Metaform V2 # В релизе V2 библиотека была переписана с нуля. После двух лет заморозки я полностью обновили сборочное окружение, перешел с Jest на современный Vitest и ввел строгие стандарты качества кода. Репозиторий библиотеки maxqwars/metaform\nГлавное отличие V2 — полный отказ от ООП в пользу функционального программирования, ориентированного на прозрачные потоки данных.\nСырой JSON (API DTO) │ ▼ Type Guard (Runtime Validation) │ ▼ Mapper (Transformation) │ ▼ JS-объект (Metaform Domain Type) Каждый метод API теперь описывается независимой цепочкой: DTO (формат сервера) ➔ Type Guard (проверка типов на лету) ➔ Mapper (трансформация в доменную модель).\nКлючевые нововведения V2 # 1. Абстракция транспорта (Runtime-agnostic) # Современный JS — это не только браузер и Node.js, но и Bun, Deno, Cloudflare Workers, Electron. Кроме того, разработчикам часто нужен полный контроль над сетевым слоем (Axios, логгирование, retry-логика, WebSocket).\nВ Metaform 2.0 появился абстрагированный Transport Layer. Библиотека больше не привязана к конкретной реализации fetch:\nВы можете использовать поставляемый из коробки fetchTransport. Вы можете передать свой транспорт на базе Axios или got. Вы можете читать данные из локальных JSON-файлов в тестах или прокидывать запросы через IPC-мост в гибридных приложениях. 2. Модульная структура «Схемы» (scheme/) # Каждая версия API теперь описывается изолированной схемой, содержащей:\ntypes.ts — DTO-структуры сервера и доменные типы Metaform. guards.ts — Type Guards для runtime-безопасности типов. mappers.ts — Чистые функции для преобразования DTO в доменную сущность. serialize-params.ts — Помощники сериализации query и path параметров. 3. Карта версий (version-map.ts) # Поддержка версий API в Metaform 2.0 стала инкрементальной. Карта версий содержит декларативное описание эндпоинтов, типов и сериализаторов.\nДобавление поддержки API v2 больше не требует мажорного релиза библиотеки или переписывания старого кода — новые схемы добавляются параллельно, оставляя старый код полностью работоспособным.\nКак выглядит код в V2 # Вызов методов стал точечным и функциональным:\nTypeScript\nimport { createFetchTrasport, getTeams } from \u0026#39;@maxqwars/metaform\u0026#39; async function main() { // Initialize the transport by specifying the base API URL const transport = createFetchTransport(\u0026#39;https://aniliberty.top/api/v1\u0026#39;) // Invoke the isolated request function, passing the transport instance const teams = await getTeams(transport, \u0026#39;v1\u0026#39;, { include: [\u0026#39;id\u0026#39;, \u0026#39;title\u0026#39;], }) console.log(teams) } main().catch(console.error) Изменения в Dev-Workflow и сборке # Этап Раньше (V1) Сейчас (V2) Сборщик Rollup + набор плагинов tsdown (быстрый специализированный бандлер) Тестирование Jest (или отсутствие тестов) Обязательное покрытие тестами в CI Линтинг Базовый ESLint Строгие правила ESLint + Prettier на commit/release Планы и Roadmap # Metaform прошла долгий путь от переусложненной структуры xconnect до легкого функционального инструмента.\nС возобновлением активного процесса разработки в планах проекта:\nПокрытие 100% методов актуального AniLiberty API. Расширение набора готовых транспортов. Активное взаимодействие с комьюнити и прием Pull Request\u0026rsquo;ов. Несмотря на прошлые ошибки и смену парадигм, ключевые принципы Metaform остаются неизменными: полная независимость от среды выполнения, строгая типизация out-of-the-box и максимальное удобство разработки.\nРепозиторий проекта # maxqwars/metaform Metaform is an open library for working with the AniLiberty Web API without external dependencies. TypeScript 2 0 ","date":"5 августа 2026","externalUrl":null,"permalink":"/posts/metaform-branch-2.0/metaform-branch-2.0/","section":"","summary":"","title":"Новая metaform V2","type":"posts"},{"content":"","externalUrl":null,"permalink":"/series/","section":"Series","summary":"","title":"Series","type":"series"},{"content":" WIP 🔨 # ","externalUrl":null,"permalink":"/about/","section":"Home","summary":"","title":"Об авторе","type":"page"}]