{"owner":"massCodeIO","repo":"massCode","hasSkills":true,"hasMcp":false,"mcpConfig":null,"found":["AGENTS.md",".agents/skills/vue-renderer-standards/SKILL.md",".agents/skills/ui-foundations/SKILL.md",".agents/skills/ui-primitives/SKILL.md",".agents/skills/i18n/SKILL.md",".agents/skills/github-workflow/SKILL.md",".agents/skills/spaces-architecture/SKILL.md",".agents/skills/release-notes/SKILL.md",".agents/skills/electron-api-and-ipc/SKILL.md",".agents/skills/documentation-workflow/SKILL.md"],"skills":{"AGENTS.md":"# Точка входа для агента massCode\n\nОтвечай всегда на русском.\n\nmassCode — это приложение на Electron + Vue 3 + TypeScript с TailwindCSS v4 в renderer, API-маршрутами на Elysia в main process, markdown vault как основным хранилищем пользовательского контента в v5 и `store.app` / `store.preferences` для локального UI state и настроек.\n\n## Всегда действующие правила\n\n- Следуй YAGNI. Предпочитай минимальную корректную реализацию вместо спекулятивных абстракций.\n- Соблюдай границы слоёв: renderer не должен напрямую обращаться к Node.js, filesystem или DB. Используй API или IPC.\n- Никогда не хардкодь пользовательские строки. Используй систему локализации.\n- Не запускай lint или тесты по всему проекту для локальной задачи. Ограничивай команды затронутыми файлами или директориями.\n- После изменений API DTO или routes запускай `pnpm api:generate`.\n- После изменений locale-файлов запускай `pnpm i18n:copy`.\n- Если задача совпадает по теме с одним из skills ниже, загружай этот skill до внесения изменений.\n\n## Skills\n\n- `.agents/skills/architecture-standards/SKILL.md`\n  Используй первым для общих правил репозитория: архитектура, naming, декомпозиция и выбор следующего skill.\n- `.agents/skills/vue-renderer-standards/SKILL.md`\n  Используй для работы с Vue renderer: `<script setup lang=\"ts\">`, правила auto-import, composables, shared state и renderer-side паттерны.\n- `.agents/skills/ui-foundations/SKILL.md`\n  Используй для базовых UI-правил: Tailwind v4, typography через `UiText` и согласованных styling decisions для renderer UI.\n- `.agents/skills/ui-primitives/SKILL.md`\n  Используй для component-level UI работы: `Ui*` components, Shadcn imports, `cn`, `cva`, notifications и правил против переизобретения primitives.\n- `.agents/skills/electron-api-and-ipc/SKILL.md`\n  Используй для API routes, DTO, IPC handlers, renderer-to-main communication и границ Electron-интеграции.\n- `.agents/skills/api-and-typing/SKILL.md`\n  Используй для generated API types, DTO-derived renderer typing и решения, когда локальный UI type оправдан, а когда нужно переиспользовать существующие API types.\n- `.agents/skills/spaces-architecture/SKILL.md`\n  Используй при изменениях, связанных с `code` / `notes` / `math` / `tools`, markdown-space state, sync behavior или `spaces:*` IPC.\n- `.agents/skills/i18n/SKILL.md`\n  Используй для правил локализации, размещения locale keys, `i18n.t(...)` и требования не хардкодить строки.\n- `.agents/skills/documentation-workflow/SKILL.md`\n  Используй для добавления или обновления документации, страниц `docs/website/documentation`, sidebar, assets и README-упоминаний фич.\n- `.agents/skills/release-notes/SKILL.md`\n  Используй для генерации release notes нового релиза в игнорируемый файл `docs/releases/<tag>.md` для вставки в GitHub release: группировка merged PR в user-facing разделы и compare-ссылка.\n- `.agents/skills/development-workflow/SKILL.md`\n  Используй для repo-specific workflow rules: scoped lint/test команды и обязательные follow-up шаги после изменений source-of-truth файлов.\n- `.agents/skills/github-workflow/SKILL.md`\n  Используй для massCode git и GitHub workflow: issue, ветки, commits, PR и подготовки к merge.\n\n## Рекомендуемый порядок загрузки\n\n- Широкая или неочевидная задача: начни с `architecture-standards`, затем загрузи профильный skill.\n- Renderer UI задача: `architecture-standards` → `vue-renderer-standards` → `ui-foundations` → `ui-primitives`.\n- API / IPC / Electron задача: `architecture-standards` → `electron-api-and-ipc`.\n- Generated types / renderer typing задача: `architecture-standards` → `api-and-typing`.\n- Spaces задача: `architecture-standards` → `spaces-architecture`.\n- Задача про текст и локализацию: `i18n`.\n- Задача про документацию или README: `documentation-workflow`.\n- Задача про release notes нового релиза: `release-notes`.\n- Workflow-чувствительная задача: `development-workflow`.\n- Задача про git / branch / commit / PR: `github-workflow`.\n\n## Основной стек\n\n- Framework: Vue 3, Composition API, `<script setup lang=\"ts\">`\n- Styling: TailwindCSS v4, `tailwind-merge`, `cva`\n- UI: локальные `src/renderer/components/ui`, Shadcn поверх `reka-ui`, `lucide-vue-next`\n- State: composables, без Pinia/Vuex\n- Backend: Electron main, Elysia API, markdown vault для контента и `electron-store` для локального состояния приложения\n- Utilities: `@vueuse/core`, `vue-sonner`\n",".agents/skills/vue-renderer-standards/SKILL.md":"---\nname: vue-renderer-standards\ndescription: Use when editing massCode renderer code in Vue 3, especially for script setup patterns, import rules, composables, shared state, and renderer-side conventions.\n---\n\n# Vue Renderer Standards\n\n## Overview\n\nRenderer в massCode строится на Vue 3 Composition API с `<script setup lang=\"ts\">`. Здесь важны строгие import rules, composable-first state sharing и запрет на прямой доступ к backend-возможностям.\n\n## Component Pattern\n\n- Используй Vue 3 Composition API и `<script setup lang=\"ts\">`.\n- Vue core (`ref`, `computed`, `watch`, `onMounted` и подобные) не импортируй вручную: они auto-imported.\n- Проектные компоненты из `src/renderer/components/` тоже не импортируй вручную: они auto-imported.\n- Локальную логику компонента держи в script, а не в template.\n\n## Manual Imports Only Where Required\n\nВсегда импортируй вручную:\n\n- composables из `@/composables`;\n- utils из `@/utils`;\n- `@vueuse/core`;\n- Electron bridge из `@/electron`;\n- Shadcn UI из `@/components/ui/shadcn/*`.\n\n## Shared State\n\n- Глобальное shared state реализуется composables без Pinia/Vuex.\n- Reactive state, который должен шариться между компонентами, объявляй на module level, вне экспортируемой функции composable.\n- Persistent UI/settings state храни через `store` из `@/electron`:\n  - `store.app` для UI state;\n  - `store.preferences` для user preferences.\n\n## VueUse First\n\n- Перед написанием нового composable сначала проверь, нет ли подходящего решения в `@vueuse/core`.\n- Кастомный composable добавляй только если готового utility реально нет.\n\n## Renderer Boundaries\n\n- Renderer не импортирует storage internals или backend-модули доступа к данным напрямую.\n- Renderer не обращается напрямую к Node.js, filesystem или storage runtime.\n- Доступ к main process возможен только через `api` или `ipc`.\n\n## Common Mistakes\n\n- Ручной импорт `ref` / `computed` / `watch`.\n- Ручной импорт локальных project components.\n- Локальный state внутри composable, который должен быть общим между несколькими компонентами.\n- Попытка “срезать путь” и импортировать backend-модуль прямо в renderer.\n",".agents/skills/ui-foundations/SKILL.md":"---\nname: ui-foundations\ndescription: Use when defining or reviewing massCode UI foundation rules such as typography, renderer styling consistency, TailwindCSS v4 usage, and when raw markup starts competing with established UI text patterns.\n---\n\n# UI Foundations\n\n## Overview\n\nUI в massCode должен оставаться визуально консистентным. Этот skill отвечает за базовые styling decisions: как относиться к typography, когда использовать established text patterns и как не скатываться в разрозненный renderer styling.\n\n## Core Rules\n\n- Базовая styling system в renderer строится на TailwindCSS v4.\n- Новые UI-экраны и состояния должны продолжать существующий visual language, а не вводить локальные правила “для одного места”.\n- Для стандартного app UI предпочитай семантические токены вроде `bg-background`, `text-muted-foreground`, `border-border`, `border-destructive/*` вместо raw palette-классов вроде `bg-white`, `text-black`, `text-green-500`, `bg-slate-900`.\n- Typography по умолчанию строится через `UiText`.\n- Не заменяй `UiText` на произвольный набор `text-*`, `font-*`, `text-muted-foreground`, если подходящий variant уже существует.\n- Если `UiText` почти подходит, лучше добавить точечные классы поверх него, чем уходить в raw typography markup.\n\n## Typography\n\n- `UiText` — базовый источник правды для текстовых размеров и muted-state.\n- `caption` и `xs` — подписи, helper text, secondary labels.\n- `sm` и `base` — основной интерфейсный текст.\n- `lg` и `xl` — усиленные title/value cases, когда это действительно нужно по hierarchy.\n- `font-mono` — только для code-like content, IDs, counts with alignment needs, readonly generated output и подобных случаев.\n- Для uppercase labels используй существующий pattern через `UiText` или согласованный tracking/uppercase стиль, а не случайную смесь utility classes в каждом месте.\n\n## Spacing And Layout Rhythm\n\n- Корневые screen/container wrappers обычно живут в ритме `space-y-4` или `space-y-6`.\n- Внутри компактных секций чаще всего `space-y-2` или `space-y-3`.\n- Grid gaps по умолчанию: `gap-2`, `gap-3`, `gap-4` в зависимости от плотности.\n- Не придумывай локальный spacing-scale для одного экрана, если существующие интервалы уже покрывают задачу.\n- Повторяющиеся content blocks должны иметь одинаковый padding и vertical rhythm.\n\n## Radius And Shadows\n\n- `rounded-md` — controls, inline boxes, compact containers.\n- `rounded-lg` — card-like blocks, dialogs, overlays, dashboard sections.\n- `rounded-xl` — preview-heavy surfaces и крупные visual blocks.\n- `rounded-full` — pills, badges, circular handles.\n- `shadow-xs` — inputs, buttons, small controls.\n- `shadow-md` и `shadow-lg` — overlays, popovers, previews, где elevation реально нужна.\n- Не вводи произвольные `rounded-[...]` и `shadow-[...]`, если стандартные токены уже подходят.\n\n## Exceptions\n\n- Raw colors допустимы, если цвет является частью самих данных или preview:\n  color pickers, contrast previews, code/image export backgrounds, diagram or visualizer nodes.\n- Если цвет вычисляется из контента или нужен для корректного контраста на пользовательском фоне, raw class или inline style допустимы.\n- Исключения не должны становиться поводом тащить raw palette в обычный application chrome.\n\n## When To Prefer This Skill\n\n- Нужно понять, как оформлять текст и подписи в новом UI.\n- Есть соблазн писать raw Tailwind typography вместо существующего text pattern.\n- В экране начинают появляться локальные styling rules, которые расходятся с остальным renderer UI.\n- Нужно принять решение на уровне визуальной базы, а не конкретного button/input/dialog.\n\n## Common Mistakes\n\n- Размазывать локальные визуальные исключения по фичам.\n- Тащить raw palette в обычный app UI без реальной причины.\n- Писать текст напрямую через произвольные utility classes там, где подходит `UiText`.\n- Делать новый экран со своим spacing rhythm вместо существующего scale.\n- Случайно смешивать small-control radii и preview-surface radii в одном и том же UI слое.\n- Считать Tailwind поводом делать каждый экран визуально “с нуля”.\n",".agents/skills/ui-primitives/SKILL.md":"---\nname: ui-primitives\ndescription: Use when building or refactoring massCode UI components with local Ui primitives or Shadcn, especially for cn, cva, notifications, and rules against reimplementing basic controls.\n---\n\n# UI Primitives\n\n## Overview\n\nБазовые UI-элементы в massCode должны собираться из существующих `Ui*` компонентов и Shadcn-паттернов. Этот skill отвечает за component-level usage rules, а не за общую визуальную базу.\n\n## Component Usage\n\n- Локальные UI-компоненты доступны через auto-import с префиксом `Ui`.\n- Базовые элементы вроде button, input, checkbox, action button не переизобретай на сыром HTML, если есть готовый `Ui*` вариант.\n- Если нужного элемента нет, сначала создай его в `src/renderer/components/ui/`, потом используй в фиче.\n\n## Buttons\n\n- Primary action должен быть явным и не конкурировать с несколькими равноправными CTA в одном контейнере.\n- Icon-only actions должны быть понятны по контексту и иметь tooltip или другой доступный label path.\n- Loading и pending actions должны использовать существующий button pattern, а не ad-hoc “disabled text swap”.\n- Destructive actions не должны выглядеть как обычные secondary controls.\n\n## Cards And Containers\n\n- Для автономных panel-like блоков используй существующий `Card` / `Ui*` container pattern, если он уже есть в области.\n- Внутренние muted blocks не нужно пересобирать разными `div`-паттернами в каждой фиче.\n- Repeated panel structure должна переезжать в shared primitive или local feature primitive, а не копироваться markup-в-маркап.\n\n## Readonly And Copyable Content\n\n- Длинный readonly output, generated text, URLs и similar content не показывай как “обычный disabled input”, если это ухудшает чтение.\n- Для copy flows используй существующий copy pattern и уведомления через `useSonner()`.\n- Readonly content должен оставаться визуально читаемым и удобно копируемым.\n\n## Styling Helpers\n\n- Для variants используй `cva`.\n- Для склейки классов используй `cn()`.\n- Не делай variants вручную строковыми `if`-цепочками там, где нужен нормальный variant API.\n\n## Shadcn Rules\n\n- Shadcn-компоненты импортируй вручную из `@/components/ui/shadcn/*`.\n- Для namespace-based компонентов используй паттерн вроде `import * as Dialog from '@/components/ui/shadcn/dialog'`.\n\n## Notifications\n\n- Для уведомлений используй `useSonner()`.\n- Не добавляй локальную, параллельную систему toast/notification внутри фичи.\n\n## Tooltip, Popover, Overlay\n\n- Tooltip — для короткого пояснения.\n- Popover — для richer inline content, picker-like content или contextual controls.\n- Не заменяй их ad-hoc overlay-разметкой без необходимости.\n- Validation и inline guidance должны использовать существующие tooltip/popover primitives, если проект уже их применяет в аналогичных местах.\n\n## Common Mistakes\n\n- Писать ещё одну кнопку или input с нуля “потому что быстрее”.\n- Склеивать сложные conditional classes без `cn()`.\n- Дублировать существующий primitive внутри feature directory вместо общего `src/renderer/components/ui/`.\n- Использовать disabled input как универсальный readonly display surface.\n- Делать overlay pattern вручную там, где уже есть Shadcn primitive.\n- Смешивать правила primitives с вопросами визуальной базы, которые должны идти в `ui-foundations`.\n",".agents/skills/i18n/SKILL.md":"---\nname: i18n\ndescription: Use when changing massCode localization, adding user-facing strings, creating locale keys, or wiring text through the project's translation system.\n---\n\n# I18n\n\n## Overview\n\nВ massCode новый пользовательский текст всегда проходит через localization system. Базовым source of truth для новых ключей считается английская локаль.\n\n## Localization Rules\n\n- Базовый язык проекта — English.\n- `en_US` остаётся базовым source of truth для новых ключей.\n- Все новые ключи сначала добавляй в `src/main/i18n/locales/en_US/`.\n- При добавлении нового ключа сразу добавляй его и в русскую локаль, чтобы `ru_RU` не отставала от базового английского набора.\n- Не хардкодь user-facing strings ни в template, ни в script logic.\n- Используй `i18n.t('namespace:key.path')` или сокращённый `i18n.t('key.path')` для default `ui` namespace.\n- Импорт `i18n` делай из `@/electron`.\n\n## After Locale Changes\n\n- После добавления или изменения locale keys запускай `pnpm i18n:copy`.\n- Не оставляй `en_US` и `ru_RU` в несинхронном состоянии.\n- Остальные локали могут догоняться отдельно контрибьюторами и не считаются обязательным блокером для каждой локальной правки.\n\n## Common Mistakes\n\n- Хардкодить новый текст “временно”.\n- Добавлять ключи не в `en_US`, а сразу в другой locale.\n- Обновить `en_US`, но забыть сразу добавить тот же ключ в `ru_RU`.\n- Использовать текст напрямую в template, хотя это часть UI.\n- Забывать `pnpm i18n:copy` после изменения locale source-of-truth.\n",".agents/skills/github-workflow/SKILL.md":"---\nname: github-workflow\ndescription: Use when working with massCode issues, branches, commits, pull requests, or merge preparation in GitHub.\n---\n\n# github-workflow\n\n## Issue\n\nЕсли работа идёт по issue, читать его через `gh`:\n\n```bash\ngh issue view <number> -R massCodeIO/massCode\n```\n\nЕсли issue описывает bug, не считай его автоматически подтверждённым.\n\nСначала:\n\n1. понять ожидаемое поведение;\n2. проверить текущее поведение в коде или воспроизвести проблему;\n3. подтвердить bug или явно зафиксировать, что он не подтверждается;\n4. только после этого переходить к ветке, фиксу и PR.\n\nЕсли bug не воспроизводится или issue описан неясно:\n\n- не начинать слепую реализацию;\n- сначала сообщить, что проблема не подтверждена, и уточнить условия или шаги воспроизведения.\n\n## Branch\n\nСоздавай ветку от `main` с префиксом по типу изменения (`feat/`, `fix/`, `chore/`, `refactor/`) и коротким описанием. Если работа идёт по issue — уместно добавить номер в конец.\n\n```bash\ngit checkout main && git pull\ngit checkout -b feat/<short-description> main\n```\n\n## PR\n\nЗаголовок PR — conventional commits:\n\n```text\ntype: description\n```\n\nПеред созданием PR предложи заголовок пользователю на подтверждение.\n\nЕсли PR закрывает существующий issue, в описании добавляй:\n\n```text\ncloses #123\n```\n\nПеред PR убедись, что релевантные проверки и тесты для затронутой области действительно прогнаны.\n\nСоздание:\n\n```bash\ngh pr create \\\n  --base main \\\n  --head <branch-name> \\\n  --title \"type: description\" \\\n  --body \"closes #<issue_number>\" \\\n  --assignee @me\n```\n\nЕсли issue нет — в `--body` кратко опиши суть изменений без служебного AI-хвоста.\n\nПосле создания PR предложи пользователю смерджить его в `main`:\n\n```bash\ngh pr merge <pr_number> -R massCodeIO/massCode --squash --delete-branch\n```\n\nПосле merge синхронизируй локальную ветку:\n\n```bash\ngit checkout main && git pull\ngit branch -d <branch-name>\n```\n\n## Commit\n\n- Только однострочный заголовок conventional commit.\n- Используй подходящий scope для коммитов и PR (`feat(notes):`, 'fix(math):).\n- Без тела, без `Co-Authored-By`.\n",".agents/skills/spaces-architecture/SKILL.md":"---\nname: spaces-architecture\ndescription: Use when working on massCode spaces such as code, notes, math, or tools, especially when changing their state, behavior, synchronization, or spaces IPC channels.\n---\n\n# Spaces Architecture\n\n## Overview\n\nmassCode использует систему Spaces для разделения функциональных областей. Это не просто UI tabs: у каждого space есть собственное состояние, свои правила обновления и свой способ синхронизации с данными в vault.\n\n## Space Model\n\n- `code` — snippets, folders, tags\n- `notes` — notes, folders, tags, markdown-based flows\n- `math` — calculation sheets и состояние math notebook\n- `tools` — developer utilities\n\nОсновные определения живут в `src/renderer/spaceDefinitions.ts`.\n\n## Space State Storage\n\n- Состояние каждого space хранится в `__spaces__/{spaceId}/.state.yaml` внутри vault.\n- Runtime helpers:\n  - `src/main/storage/providers/markdown/runtime/spaces.ts`\n  - `src/main/storage/providers/markdown/runtime/spaceState.ts`\n- Директория `__spaces__/` — служебная часть vault для состояния spaces.\n\n## Persistence Rules\n\n- Запись состояния spaces использует ту же debounce/flush инфраструктуру, что и `state.json`.\n- Не ломай совместимость с `pendingStateWriteByPath` и flush-on-exit поведением.\n- Если меняешь способ записи, учитывай сценарий завершения приложения до явного ручного flush.\n\n## IPC Rules\n\n- Space-specific IPC handlers живут в `src/main/ipc/handlers/spaces.ts`.\n- Текущие math handlers:\n  - `spaces:math:read`\n  - `spaces:math:write`\n- Если добавляется новый `spaces:*` flow, он должен работать через общую модель состояния spaces, а не в обход неё.\n\n## Space-Aware Sync\n\n- `system:storage-synced` обновляет активное пространство через `getActiveSpaceId()`.\n- Ожидаемое поведение:\n  - `code` → refresh folders + snippets\n  - `notes` → refresh notes + note folders\n  - `math` → `reloadFromDisk()` через `useMathNotebook()`\n  - `tools` → no-op\n- Изменения, которые уже сохранены в vault, должны вызывать `markPersistedStorageMutation()`, чтобы не создавать sync loops.\n\n## Common Mistakes\n\n- Считать spaces только UI-концепцией и забывать, что у них есть собственное состояние и правила синхронизации.\n- Писать состояние space в обход общих markdown runtime helpers.\n- Добавлять mutation без `markPersistedStorageMutation()`.\n- Ломать согласованность между состоянием space, helpers и sync behavior.\n",".agents/skills/release-notes/SKILL.md":"---\nname: release-notes\ndescription: Use when generating massCode release notes for a GitHub release. Writes the notes to a gitignored file `docs/releases/<tag>.md` for the user to paste into the GitHub release. Use when summarizing merged PRs of a version into a consistent release notes structure.\n---\n\n# Release Notes\n\n## Overview\n\nЭтот skill генерирует release notes одного релиза `vX.Y.Z` для вставки в GitHub release. Цель — единая повторяемая структура от релиза к релизу.\n\nНе трогай `docs/website/download/latest-release.md` — это отдельная repo-страница со своим форматом.\n\n## Source Of Truth\n\n- Содержимое выводи из merged PR между предыдущим и новым тегом, не из памяти.\n- Список изменений бери так:\n  `git log --first-parent --oneline <prev-tag>..<new-tag>` (например `v5.5.0..v5.6.0`).\n- Если новый тег ещё не создан, используй `<prev-tag>..HEAD` и спроси/подтверди номер новой версии.\n- Поведение значимых фич проверяй в коде или в `docs/website/documentation`, прежде чем формулировать, если оно неочевидно из заголовка PR.\n\n## Output\n\n- Записывай результат в файл `docs/releases/<new-tag>.md` (например `docs/releases/v5.6.0.md`). Папка `docs/releases` в `.gitignore`, это рабочий буфер, а не часть репозитория.\n- Пиши именно в файл, а не выводом в терминал: так пользователь копирует чистый markdown без переносов строк, которые добавляет терминал.\n- После записи коротко сообщи путь к файлу и при необходимости покажи итог. Не коммить файл.\n\n## Format\n\nФайл содержит один markdown-блок в этой структуре и порядке:\n\n```\n## <Feature Name>\n\n<1-2 абзаца: что это и что даёт пользователю.>\n\n## <Another Feature Name>\n\n<1-2 абзаца.>\n\n## Workflow Improvements\n\n- <мелкое улучшение>\n- <мелкое улучшение>\n\n## Fixes\n\n- <исправление>\n- <исправление>\n\n**Full Changelog**: https://github.com/massCodeIO/massCode/compare/<prev-tag>...<new-tag>\n```\n\nПравила структуры:\n\n- Начинай прямо с тематических `##`-разделов. Не добавляй заголовок версии `# vX.Y.Z` (его даёт сам GitHub release), frontmatter или `<AssetsDownload />` — это артефакты repo-страницы.\n- Один `##`-раздел на каждую значимую фичу или связную группу фич.\n- `## Workflow Improvements` и `## Fixes` включай только если для них есть содержимое.\n- Compare-ссылка всегда последней строкой, с актуальными предыдущим и новым тегами.\n\n## What To Include\n\n- User-facing изменения: новые spaces и фичи, заметные улучшения workflow, видимые исправления.\n- Крупную фичу выноси в отдельный `##`-раздел с 1-2 абзацами о пользе для пользователя.\n- Мелкие улучшения собирай в `## Workflow Improvements` буллетами.\n- Исправления собирай в `## Fixes` буллетами, по одному на исправление.\n\n## What To Omit\n\n- Чисто внутренние коммиты: `ci`, `build`, `chore`, рефакторинг, bump зависимостей, релизные служебные коммиты (`build: release vX.Y.Z`).\n- Исключение: выноси платформенные изменения, заметные пользователю (например code signing и notarization на macOS), в `## Workflow Improvements`.\n- Не описывай детали реализации; пиши о результате для пользователя.\n\n## Writing Style\n\n- Английский, спокойный фактический тон. Что делает фича и зачем она пользователю, без маркетинговых превосходных степеней.\n- Никаких em dash. Это общее правило репозитория.\n- Имена spaces пиши консистентно: `Code`, `Notes`, `Math Notebook`, `Drawings`, `HTTP`, `Tools`. Не смешивай `Code` и `Snippets` как имя пространства.\n- `snippet` — единица контента внутри пространства Code, а не имя пространства. В Fixes допустимо «snippet fences», «snippet sync», но пространство всё равно называется Code.\n- Code identifiers, расширения файлов и токены оборачивай в backticks (`` `.excalidraw` ``, `` `@` ``, `` `Esc` ``).\n- Shortcuts указывай как в интерфейсе; macOS и Windows/Linux варианты различай, если они отличаются.\n\n## Common Mistakes\n\n- Перечислять коммиты дословно вместо группировки в user-facing разделы.\n- Включать `ci` / `build` / `chore` шум, который не виден пользователю.\n- Добавлять `# vX.Y.Z`, frontmatter или `<AssetsDownload />` (это формат repo-страницы, а не GitHub release).\n- Выводить нотис простыней в терминал вместо файла `docs/releases/<new-tag>.md` (терминал ломает переносы строк при копировании).\n- Коммитить файл из `docs/releases` — это игнорируемый рабочий буфер.\n- Смешивать имена пространств (`Code` против `Snippets`) внутри одного документа.\n- Описывать детали реализации вместо пользы для пользователя.\n- Забыть обновить compare-ссылку на актуальные теги.\n- Использовать em dash вопреки правилу репозитория.\n",".agents/skills/electron-api-and-ipc/SKILL.md":"---\nname: electron-api-and-ipc\ndescription: Use when changing massCode API routes, DTOs, IPC handlers, Electron bridges, or any renderer-to-main communication and storage-access boundaries.\n---\n\n# Electron API And IPC\n\n## Overview\n\nВсе backend-возможности massCode живут в main process. Renderer получает доступ к данным и системным операциям только через Elysia API или IPC channels.\n\n## Renderer Access Rules\n\n- В renderer для данных используй `import { api } from '~/renderer/services/api'`.\n- В renderer для системных операций используй `ipc.invoke('channel:action', payload)`.\n- Electron API из renderer доступен только через `src/renderer/electron.ts`.\n- Никогда не импортируй storage internals или backend-модули напрямую в renderer.\n\n## New API Endpoints\n\nПри добавлении нового endpoint:\n\n1. создай DTO в `src/main/api/dto/`;\n2. добавь route в `src/main/api/routes/`;\n3. запусти `pnpm api:generate`, чтобы обновить клиент.\n\nНе оставляй API-клиент рассинхронизированным с route/DTO изменениями.\n\n## IPC Conventions\n\n- Для filesystem и system ops используй `ipc.invoke(...)`.\n- Каналы должны укладываться в семейства:\n  - `fs:*`\n  - `system:*`\n  - `db:*` — legacy или migration flows, не основной путь для новой функциональности\n  - `main-menu:*`\n  - `prettier:*`\n  - `spaces:*`\n  - `theme:*`\n\n## Good Boundaries\n\n- Renderer формирует intent и payload.\n- Main/API работает с данными приложения, файловой системой и system APIs.\n- Ответ возвращается обратно в renderer в виде DTO или IPC result, а не через shared mutable backend module.\n\n## Common Mistakes\n\n- Тянуть backend-модуль напрямую в renderer ради “удобства”.\n- Менять DTO/route без `pnpm api:generate`.\n- Добавлять system/file behavior в renderer вместо IPC handler.\n- Добавлять новые `db:*` flows там, где задача должна идти через текущую API/IPC модель приложения.\n- Создавать ad-hoc каналы, которые не укладываются в существующие channel families.\n",".agents/skills/documentation-workflow/SKILL.md":"---\nname: documentation-workflow\ndescription: Use when adding or updating massCode documentation, documenting a new feature, changing docs website pages, adding docs assets, updating the VitePress sidebar, or adding README feature mentions.\n---\n\n# Documentation Workflow\n\n## Overview\n\nДокументация massCode живёт в VitePress сайте в `docs/website/documentation`. README — это общий обзор проекта, а не источник детального описания фич.\n\n## Documentation Surfaces\n\n- Документация фич: `docs/website/documentation/**`\n- Sidebar документации: `docs/website/.vitepress/config.mts`\n- Assets документации: `docs/website/public/**`\n- Overview документации: `docs/website/documentation/index.md`\n- Overview проекта: `README.md`\n\n## Core Rules\n\n- Проверяй поведение фичи в коде или существующей документации; не документируй по памяти.\n- Используй `rg`, чтобы найти связанные страницы, скриншоты, shortcuts, labels и существующие формулировки.\n- Если целевая версия известна, используй именно её. Если версия неизвестна, не придумывай её.\n- Пользовательская документация сайта пишется на английском, в стиле существующих docs pages.\n- Добавляй или обновляй наиболее конкретную страницу в `docs/website/documentation`.\n- Для новых страниц используй frontmatter с `title` и `description`.\n- Добавляй страницу в `docs/website/.vitepress/config.mts` только если она должна появиться в навигации.\n- Ссылайся из `docs/website/documentation/index.md` только на широкие, cross-cutting фичи.\n- Пиши короткими task-oriented секциями. Предпочитай пользовательские флоу, а не детали реализации.\n- Shortcuts документируй через `<kbd>...</kbd>` и указывай macOS плюс Windows/Linux варианты, если они отличаются.\n\n## Version Availability\n\n- Перед добавлением или изменением `<AppVersion>` проверяй историю фичи в коде, документации или предыдущем релизном теге.\n- Считай `<AppVersion text=\">=x.y\" />` минимальной версией, где появилась ровно описываемая возможность, а не версией её последнего улучшения.\n- Ставь marker на уровне страницы или общего раздела только когда вся описываемая сущность впервые появилась в этой версии.\n- Если новый релиз расширяет существующую фичу, сохраняй её исходный marker или отсутствие marker, а новую версию указывай только у отдельного подпункта или предложения про улучшение.\n- Разделяй смешанное описание на базовую возможность и versioned enhancement, если общий marker создаёт впечатление, что старая возможность раньше была недоступна.\n- Не добавляй version marker для bugfix или внутренней переработки без нового пользовательского сценария. Локально отмечай изменение формата хранения, если оно влияет на совместимость.\n\nПример: если custom folder icons существуют с 3.7, а Emoji и Upload добавлены в 5.9, оставляй `>=3.7` у базовой возможности и ставь `>=5.9` только у подпункта про Emoji и Upload.\n\n## Documentation Weight\n\n- Перед созданием страницы или раздела оцени самостоятельность пользовательского сценария, количество шагов, настроек и ограничений.\n- Описывай мелкое одношаговое действие одной строкой или буллетом внутри существующего релевантного раздела.\n- Создавай отдельный раздел для самостоятельного workflow с несколькими шагами, вариантами, настройками или важными ограничениями.\n- Выбирай одно основное место для подробного описания cross-cutting фичи. В других страницах оставляй короткое упоминание или ссылку вместо повторения полного объяснения.\n- Оставляй bugfix, внутреннюю оптимизацию и implementation detail только в release notes, если они не меняют пользовательский сценарий или требования совместимости.\n\n## Callouts\n\n- Используй `warning` для риска потери данных, несовместимости, необратимого действия или существенного security-ограничения.\n- Используй `info` для автоматической миграции и неочевидного поведения, которое помогает правильно понять основной workflow.\n- Оставляй основные инструкции обычным текстом; callout должен выделять контекст или исключение, а не содержать весь сценарий.\n- Объединяй связанные риски в один callout и избегай нескольких соседних блоков, если их можно прочитать как одно сообщение.\n- Добавляй короткий предметный заголовок, например `::: warning Compatibility` или `::: info Automatic migration`.\n\n## VitePress Markdown Gotchas\n\n- VitePress компилирует markdown как Vue-компонент, поэтому `{{ ... }}` трактуется как Vue-интерполяция и **исчезает** из вывода.\n- Fenced-блоки (` ``` `) защищены автоматически — внутри них `{{var}}` рендерится буквально.\n- **Инлайн-код в backticks НЕ защищён**: `` `{{variables}}` `` отрендерится пустым. Чтобы вывести литеральные двойные фигурные скобки в тексте или таблице, оборачивай в `v-pre`:\n  `<code v-pre>{{variables}}</code>`\n- Это же касается любых других Vue-конструкций (`{{ }}`, директивы) в произвольном тексте страницы.\n\n## Images And Assets Rules\n\n- Картинки для docs клади в `docs/website/public`.\n- Ссылайся на картинки через `withBase`, например:\n  `<img :src=\"withBase('/feature.png')\">`\n- Если страница использует `withBase`, добавь соответствующий script block:\n  `import { withBase } from 'vitepress'`\n- Используй скриншоты только когда они реально объясняют фичу. Не добавляй декоративные изображения.\n\n## README Rules\n\n- Добавляй README-упоминания только для user-facing фич, которые важны на уровне общего обзора проекта.\n- Держи README copy коротким и product-level; подробное использование должно быть в `docs/website/documentation`.\n- Не пиши в README, когда фича была добавлена. Version availability должна жить в docs pages или release notes.\n- Не ставь новую фичу первой автоматически. Сохраняй текущую информационную архитектуру: сначала основные spaces/features, затем широкие workflow helpers, если пользователь не попросил иначе.\n\n## Validation\n\n- Запускай `git diff --check`.\n- Для изменений docs website запускай `pnpm -C docs/website build`.\n- Если нужно форматирование, ограничивай его изменёнными файлами и избегай широкого churn в config-файлах.\n- Не коммить без явной просьбы пользователя. Для commit или PR загружай `github-workflow`.\n\n## Common Mistakes\n\n- Добавлять README-only документацию для фичи, которой нужна настоящая docs page.\n- Забывать VitePress sidebar для новой страницы, которая должна быть в навигации.\n- Добавлять version availability в README.\n- Переносить `<AppVersion>` всего существующего раздела на версию, в которой фича лишь получила улучшение.\n- Создавать отдельный раздел для одношаговой мелкой фичи, которую достаточно упомянуть в существующем разделе.\n- Повторять полное описание cross-cutting фичи на нескольких страницах вместо одного основного места и коротких упоминаний.\n- Использовать callout для обычной инструкции без риска, совместимости или неочевидного поведения.\n- Документировать shortcuts или поведение без проверки реализации.\n- Запускать широкие formatters, которые переписывают существующий стиль docs config.\n- Писать литеральные `{{ ... }}` в инлайн-коде без `v-pre` — VitePress съест их как Vue-интерполяцию.\n"},"files":{"AGENTS.md":"# Точка входа для агента massCode\n\nОтвечай всегда на русском.\n\nmassCode — это приложение на Electron + Vue 3 + TypeScript с TailwindCSS v4 в renderer, API-маршрутами на Elysia в main process, markdown vault как основным хранилищем пользовательского контента в v5 и `store.app` / `store.preferences` для локального UI state и настроек.\n\n## Всегда действующие правила\n\n- Следуй YAGNI. Предпочитай минимальную корректную реализацию вместо спекулятивных абстракций.\n- Соблюдай границы слоёв: renderer не должен напрямую обращаться к Node.js, filesystem или DB. Используй API или IPC.\n- Никогда не хардкодь пользовательские строки. Используй систему локализации.\n- Не запускай lint или тесты по всему проекту для локальной задачи. Ограничивай команды затронутыми файлами или директориями.\n- После изменений API DTO или routes запускай `pnpm api:generate`.\n- После изменений locale-файлов запускай `pnpm i18n:copy`.\n- Если задача совпадает по теме с одним из skills ниже, загружай этот skill до внесения изменений.\n\n## Skills\n\n- `.agents/skills/architecture-standards/SKILL.md`\n  Используй первым для общих правил репозитория: архитектура, naming, декомпозиция и выбор следующего skill.\n- `.agents/skills/vue-renderer-standards/SKILL.md`\n  Используй для работы с Vue renderer: `<script setup lang=\"ts\">`, правила auto-import, composables, shared state и renderer-side паттерны.\n- `.agents/skills/ui-foundations/SKILL.md`\n  Используй для базовых UI-правил: Tailwind v4, typography через `UiText` и согласованных styling decisions для renderer UI.\n- `.agents/skills/ui-primitives/SKILL.md`\n  Используй для component-level UI работы: `Ui*` components, Shadcn imports, `cn`, `cva`, notifications и правил против переизобретения primitives.\n- `.agents/skills/electron-api-and-ipc/SKILL.md`\n  Используй для API routes, DTO, IPC handlers, renderer-to-main communication и границ Electron-интеграции.\n- `.agents/skills/api-and-typing/SKILL.md`\n  Используй для generated API types, DTO-derived renderer typing и решения, когда локальный UI type оправдан, а когда нужно переиспользовать существующие API types.\n- `.agents/skills/spaces-architecture/SKILL.md`\n  Используй при изменениях, связанных с `code` / `notes` / `math` / `tools`, markdown-space state, sync behavior или `spaces:*` IPC.\n- `.agents/skills/i18n/SKILL.md`\n  Используй для правил локализации, размещения locale keys, `i18n.t(...)` и требования не хардкодить строки.\n- `.agents/skills/documentation-workflow/SKILL.md`\n  Используй для добавления или обновления документации, страниц `docs/website/documentation`, sidebar, assets и README-упоминаний фич.\n- `.agents/skills/release-notes/SKILL.md`\n  Используй для генерации release notes нового релиза в игнорируемый файл `docs/releases/<tag>.md` для вставки в GitHub release: группировка merged PR в user-facing разделы и compare-ссылка.\n- `.agents/skills/development-workflow/SKILL.md`\n  Используй для repo-specific workflow rules: scoped lint/test команды и обязательные follow-up шаги после изменений source-of-truth файлов.\n- `.agents/skills/github-workflow/SKILL.md`\n  Используй для massCode git и GitHub workflow: issue, ветки, commits, PR и подготовки к merge.\n\n## Рекомендуемый порядок загрузки\n\n- Широкая или неочевидная задача: начни с `architecture-standards`, затем загрузи профильный skill.\n- Renderer UI задача: `architecture-standards` → `vue-renderer-standards` → `ui-foundations` → `ui-primitives`.\n- API / IPC / Electron задача: `architecture-standards` → `electron-api-and-ipc`.\n- Generated types / renderer typing задача: `architecture-standards` → `api-and-typing`.\n- Spaces задача: `architecture-standards` → `spaces-architecture`.\n- Задача про текст и локализацию: `i18n`.\n- Задача про документацию или README: `documentation-workflow`.\n- Задача про release notes нового релиза: `release-notes`.\n- Workflow-чувствительная задача: `development-workflow`.\n- Задача про git / branch / commit / PR: `github-workflow`.\n\n## Основной стек\n\n- Framework: Vue 3, Composition API, `<script setup lang=\"ts\">`\n- Styling: TailwindCSS v4, `tailwind-merge`, `cva`\n- UI: локальные `src/renderer/components/ui`, Shadcn поверх `reka-ui`, `lucide-vue-next`\n- State: composables, без Pinia/Vuex\n- Backend: Electron main, Elysia API, markdown vault для контента и `electron-store` для локального состояния приложения\n- Utilities: `@vueuse/core`, `vue-sonner`\n",".agents/skills/vue-renderer-standards/SKILL.md":"---\nname: vue-renderer-standards\ndescription: Use when editing massCode renderer code in Vue 3, especially for script setup patterns, import rules, composables, shared state, and renderer-side conventions.\n---\n\n# Vue Renderer Standards\n\n## Overview\n\nRenderer в massCode строится на Vue 3 Composition API с `<script setup lang=\"ts\">`. Здесь важны строгие import rules, composable-first state sharing и запрет на прямой доступ к backend-возможностям.\n\n## Component Pattern\n\n- Используй Vue 3 Composition API и `<script setup lang=\"ts\">`.\n- Vue core (`ref`, `computed`, `watch`, `onMounted` и подобные) не импортируй вручную: они auto-imported.\n- Проектные компоненты из `src/renderer/components/` тоже не импортируй вручную: они auto-imported.\n- Локальную логику компонента держи в script, а не в template.\n\n## Manual Imports Only Where Required\n\nВсегда импортируй вручную:\n\n- composables из `@/composables`;\n- utils из `@/utils`;\n- `@vueuse/core`;\n- Electron bridge из `@/electron`;\n- Shadcn UI из `@/components/ui/shadcn/*`.\n\n## Shared State\n\n- Глобальное shared state реализуется composables без Pinia/Vuex.\n- Reactive state, который должен шариться между компонентами, объявляй на module level, вне экспортируемой функции composable.\n- Persistent UI/settings state храни через `store` из `@/electron`:\n  - `store.app` для UI state;\n  - `store.preferences` для user preferences.\n\n## VueUse First\n\n- Перед написанием нового composable сначала проверь, нет ли подходящего решения в `@vueuse/core`.\n- Кастомный composable добавляй только если готового utility реально нет.\n\n## Renderer Boundaries\n\n- Renderer не импортирует storage internals или backend-модули доступа к данным напрямую.\n- Renderer не обращается напрямую к Node.js, filesystem или storage runtime.\n- Доступ к main process возможен только через `api` или `ipc`.\n\n## Common Mistakes\n\n- Ручной импорт `ref` / `computed` / `watch`.\n- Ручной импорт локальных project components.\n- Локальный state внутри composable, который должен быть общим между несколькими компонентами.\n- Попытка “срезать путь” и импортировать backend-модуль прямо в renderer.\n",".agents/skills/ui-foundations/SKILL.md":"---\nname: ui-foundations\ndescription: Use when defining or reviewing massCode UI foundation rules such as typography, renderer styling consistency, TailwindCSS v4 usage, and when raw markup starts competing with established UI text patterns.\n---\n\n# UI Foundations\n\n## Overview\n\nUI в massCode должен оставаться визуально консистентным. Этот skill отвечает за базовые styling decisions: как относиться к typography, когда использовать established text patterns и как не скатываться в разрозненный renderer styling.\n\n## Core Rules\n\n- Базовая styling system в renderer строится на TailwindCSS v4.\n- Новые UI-экраны и состояния должны продолжать существующий visual language, а не вводить локальные правила “для одного места”.\n- Для стандартного app UI предпочитай семантические токены вроде `bg-background`, `text-muted-foreground`, `border-border`, `border-destructive/*` вместо raw palette-классов вроде `bg-white`, `text-black`, `text-green-500`, `bg-slate-900`.\n- Typography по умолчанию строится через `UiText`.\n- Не заменяй `UiText` на произвольный набор `text-*`, `font-*`, `text-muted-foreground`, если подходящий variant уже существует.\n- Если `UiText` почти подходит, лучше добавить точечные классы поверх него, чем уходить в raw typography markup.\n\n## Typography\n\n- `UiText` — базовый источник правды для текстовых размеров и muted-state.\n- `caption` и `xs` — подписи, helper text, secondary labels.\n- `sm` и `base` — основной интерфейсный текст.\n- `lg` и `xl` — усиленные title/value cases, когда это действительно нужно по hierarchy.\n- `font-mono` — только для code-like content, IDs, counts with alignment needs, readonly generated output и подобных случаев.\n- Для uppercase labels используй существующий pattern через `UiText` или согласованный tracking/uppercase стиль, а не случайную смесь utility classes в каждом месте.\n\n## Spacing And Layout Rhythm\n\n- Корневые screen/container wrappers обычно живут в ритме `space-y-4` или `space-y-6`.\n- Внутри компактных секций чаще всего `space-y-2` или `space-y-3`.\n- Grid gaps по умолчанию: `gap-2`, `gap-3`, `gap-4` в зависимости от плотности.\n- Не придумывай локальный spacing-scale для одного экрана, если существующие интервалы уже покрывают задачу.\n- Повторяющиеся content blocks должны иметь одинаковый padding и vertical rhythm.\n\n## Radius And Shadows\n\n- `rounded-md` — controls, inline boxes, compact containers.\n- `rounded-lg` — card-like blocks, dialogs, overlays, dashboard sections.\n- `rounded-xl` — preview-heavy surfaces и крупные visual blocks.\n- `rounded-full` — pills, badges, circular handles.\n- `shadow-xs` — inputs, buttons, small controls.\n- `shadow-md` и `shadow-lg` — overlays, popovers, previews, где elevation реально нужна.\n- Не вводи произвольные `rounded-[...]` и `shadow-[...]`, если стандартные токены уже подходят.\n\n## Exceptions\n\n- Raw colors допустимы, если цвет является частью самих данных или preview:\n  color pickers, contrast previews, code/image export backgrounds, diagram or visualizer nodes.\n- Если цвет вычисляется из контента или нужен для корректного контраста на пользовательском фоне, raw class или inline style допустимы.\n- Исключения не должны становиться поводом тащить raw palette в обычный application chrome.\n\n## When To Prefer This Skill\n\n- Нужно понять, как оформлять текст и подписи в новом UI.\n- Есть соблазн писать raw Tailwind typography вместо существующего text pattern.\n- В экране начинают появляться локальные styling rules, которые расходятся с остальным renderer UI.\n- Нужно принять решение на уровне визуальной базы, а не конкретного button/input/dialog.\n\n## Common Mistakes\n\n- Размазывать локальные визуальные исключения по фичам.\n- Тащить raw palette в обычный app UI без реальной причины.\n- Писать текст напрямую через произвольные utility classes там, где подходит `UiText`.\n- Делать новый экран со своим spacing rhythm вместо существующего scale.\n- Случайно смешивать small-control radii и preview-surface radii в одном и том же UI слое.\n- Считать Tailwind поводом делать каждый экран визуально “с нуля”.\n",".agents/skills/ui-primitives/SKILL.md":"---\nname: ui-primitives\ndescription: Use when building or refactoring massCode UI components with local Ui primitives or Shadcn, especially for cn, cva, notifications, and rules against reimplementing basic controls.\n---\n\n# UI Primitives\n\n## Overview\n\nБазовые UI-элементы в massCode должны собираться из существующих `Ui*` компонентов и Shadcn-паттернов. Этот skill отвечает за component-level usage rules, а не за общую визуальную базу.\n\n## Component Usage\n\n- Локальные UI-компоненты доступны через auto-import с префиксом `Ui`.\n- Базовые элементы вроде button, input, checkbox, action button не переизобретай на сыром HTML, если есть готовый `Ui*` вариант.\n- Если нужного элемента нет, сначала создай его в `src/renderer/components/ui/`, потом используй в фиче.\n\n## Buttons\n\n- Primary action должен быть явным и не конкурировать с несколькими равноправными CTA в одном контейнере.\n- Icon-only actions должны быть понятны по контексту и иметь tooltip или другой доступный label path.\n- Loading и pending actions должны использовать существующий button pattern, а не ad-hoc “disabled text swap”.\n- Destructive actions не должны выглядеть как обычные secondary controls.\n\n## Cards And Containers\n\n- Для автономных panel-like блоков используй существующий `Card` / `Ui*` container pattern, если он уже есть в области.\n- Внутренние muted blocks не нужно пересобирать разными `div`-паттернами в каждой фиче.\n- Repeated panel structure должна переезжать в shared primitive или local feature primitive, а не копироваться markup-в-маркап.\n\n## Readonly And Copyable Content\n\n- Длинный readonly output, generated text, URLs и similar content не показывай как “обычный disabled input”, если это ухудшает чтение.\n- Для copy flows используй существующий copy pattern и уведомления через `useSonner()`.\n- Readonly content должен оставаться визуально читаемым и удобно копируемым.\n\n## Styling Helpers\n\n- Для variants используй `cva`.\n- Для склейки классов используй `cn()`.\n- Не делай variants вручную строковыми `if`-цепочками там, где нужен нормальный variant API.\n\n## Shadcn Rules\n\n- Shadcn-компоненты импортируй вручную из `@/components/ui/shadcn/*`.\n- Для namespace-based компонентов используй паттерн вроде `import * as Dialog from '@/components/ui/shadcn/dialog'`.\n\n## Notifications\n\n- Для уведомлений используй `useSonner()`.\n- Не добавляй локальную, параллельную систему toast/notification внутри фичи.\n\n## Tooltip, Popover, Overlay\n\n- Tooltip — для короткого пояснения.\n- Popover — для richer inline content, picker-like content или contextual controls.\n- Не заменяй их ad-hoc overlay-разметкой без необходимости.\n- Validation и inline guidance должны использовать существующие tooltip/popover primitives, если проект уже их применяет в аналогичных местах.\n\n## Common Mistakes\n\n- Писать ещё одну кнопку или input с нуля “потому что быстрее”.\n- Склеивать сложные conditional classes без `cn()`.\n- Дублировать существующий primitive внутри feature directory вместо общего `src/renderer/components/ui/`.\n- Использовать disabled input как универсальный readonly display surface.\n- Делать overlay pattern вручную там, где уже есть Shadcn primitive.\n- Смешивать правила primitives с вопросами визуальной базы, которые должны идти в `ui-foundations`.\n",".agents/skills/i18n/SKILL.md":"---\nname: i18n\ndescription: Use when changing massCode localization, adding user-facing strings, creating locale keys, or wiring text through the project's translation system.\n---\n\n# I18n\n\n## Overview\n\nВ massCode новый пользовательский текст всегда проходит через localization system. Базовым source of truth для новых ключей считается английская локаль.\n\n## Localization Rules\n\n- Базовый язык проекта — English.\n- `en_US` остаётся базовым source of truth для новых ключей.\n- Все новые ключи сначала добавляй в `src/main/i18n/locales/en_US/`.\n- При добавлении нового ключа сразу добавляй его и в русскую локаль, чтобы `ru_RU` не отставала от базового английского набора.\n- Не хардкодь user-facing strings ни в template, ни в script logic.\n- Используй `i18n.t('namespace:key.path')` или сокращённый `i18n.t('key.path')` для default `ui` namespace.\n- Импорт `i18n` делай из `@/electron`.\n\n## After Locale Changes\n\n- После добавления или изменения locale keys запускай `pnpm i18n:copy`.\n- Не оставляй `en_US` и `ru_RU` в несинхронном состоянии.\n- Остальные локали могут догоняться отдельно контрибьюторами и не считаются обязательным блокером для каждой локальной правки.\n\n## Common Mistakes\n\n- Хардкодить новый текст “временно”.\n- Добавлять ключи не в `en_US`, а сразу в другой locale.\n- Обновить `en_US`, но забыть сразу добавить тот же ключ в `ru_RU`.\n- Использовать текст напрямую в template, хотя это часть UI.\n- Забывать `pnpm i18n:copy` после изменения locale source-of-truth.\n",".agents/skills/github-workflow/SKILL.md":"---\nname: github-workflow\ndescription: Use when working with massCode issues, branches, commits, pull requests, or merge preparation in GitHub.\n---\n\n# github-workflow\n\n## Issue\n\nЕсли работа идёт по issue, читать его через `gh`:\n\n```bash\ngh issue view <number> -R massCodeIO/massCode\n```\n\nЕсли issue описывает bug, не считай его автоматически подтверждённым.\n\nСначала:\n\n1. понять ожидаемое поведение;\n2. проверить текущее поведение в коде или воспроизвести проблему;\n3. подтвердить bug или явно зафиксировать, что он не подтверждается;\n4. только после этого переходить к ветке, фиксу и PR.\n\nЕсли bug не воспроизводится или issue описан неясно:\n\n- не начинать слепую реализацию;\n- сначала сообщить, что проблема не подтверждена, и уточнить условия или шаги воспроизведения.\n\n## Branch\n\nСоздавай ветку от `main` с префиксом по типу изменения (`feat/`, `fix/`, `chore/`, `refactor/`) и коротким описанием. Если работа идёт по issue — уместно добавить номер в конец.\n\n```bash\ngit checkout main && git pull\ngit checkout -b feat/<short-description> main\n```\n\n## PR\n\nЗаголовок PR — conventional commits:\n\n```text\ntype: description\n```\n\nПеред созданием PR предложи заголовок пользователю на подтверждение.\n\nЕсли PR закрывает существующий issue, в описании добавляй:\n\n```text\ncloses #123\n```\n\nПеред PR убедись, что релевантные проверки и тесты для затронутой области действительно прогнаны.\n\nСоздание:\n\n```bash\ngh pr create \\\n  --base main \\\n  --head <branch-name> \\\n  --title \"type: description\" \\\n  --body \"closes #<issue_number>\" \\\n  --assignee @me\n```\n\nЕсли issue нет — в `--body` кратко опиши суть изменений без служебного AI-хвоста.\n\nПосле создания PR предложи пользователю смерджить его в `main`:\n\n```bash\ngh pr merge <pr_number> -R massCodeIO/massCode --squash --delete-branch\n```\n\nПосле merge синхронизируй локальную ветку:\n\n```bash\ngit checkout main && git pull\ngit branch -d <branch-name>\n```\n\n## Commit\n\n- Только однострочный заголовок conventional commit.\n- Используй подходящий scope для коммитов и PR (`feat(notes):`, 'fix(math):).\n- Без тела, без `Co-Authored-By`.\n",".agents/skills/spaces-architecture/SKILL.md":"---\nname: spaces-architecture\ndescription: Use when working on massCode spaces such as code, notes, math, or tools, especially when changing their state, behavior, synchronization, or spaces IPC channels.\n---\n\n# Spaces Architecture\n\n## Overview\n\nmassCode использует систему Spaces для разделения функциональных областей. Это не просто UI tabs: у каждого space есть собственное состояние, свои правила обновления и свой способ синхронизации с данными в vault.\n\n## Space Model\n\n- `code` — snippets, folders, tags\n- `notes` — notes, folders, tags, markdown-based flows\n- `math` — calculation sheets и состояние math notebook\n- `tools` — developer utilities\n\nОсновные определения живут в `src/renderer/spaceDefinitions.ts`.\n\n## Space State Storage\n\n- Состояние каждого space хранится в `__spaces__/{spaceId}/.state.yaml` внутри vault.\n- Runtime helpers:\n  - `src/main/storage/providers/markdown/runtime/spaces.ts`\n  - `src/main/storage/providers/markdown/runtime/spaceState.ts`\n- Директория `__spaces__/` — служебная часть vault для состояния spaces.\n\n## Persistence Rules\n\n- Запись состояния spaces использует ту же debounce/flush инфраструктуру, что и `state.json`.\n- Не ломай совместимость с `pendingStateWriteByPath` и flush-on-exit поведением.\n- Если меняешь способ записи, учитывай сценарий завершения приложения до явного ручного flush.\n\n## IPC Rules\n\n- Space-specific IPC handlers живут в `src/main/ipc/handlers/spaces.ts`.\n- Текущие math handlers:\n  - `spaces:math:read`\n  - `spaces:math:write`\n- Если добавляется новый `spaces:*` flow, он должен работать через общую модель состояния spaces, а не в обход неё.\n\n## Space-Aware Sync\n\n- `system:storage-synced` обновляет активное пространство через `getActiveSpaceId()`.\n- Ожидаемое поведение:\n  - `code` → refresh folders + snippets\n  - `notes` → refresh notes + note folders\n  - `math` → `reloadFromDisk()` через `useMathNotebook()`\n  - `tools` → no-op\n- Изменения, которые уже сохранены в vault, должны вызывать `markPersistedStorageMutation()`, чтобы не создавать sync loops.\n\n## Common Mistakes\n\n- Считать spaces только UI-концепцией и забывать, что у них есть собственное состояние и правила синхронизации.\n- Писать состояние space в обход общих markdown runtime helpers.\n- Добавлять mutation без `markPersistedStorageMutation()`.\n- Ломать согласованность между состоянием space, helpers и sync behavior.\n",".agents/skills/release-notes/SKILL.md":"---\nname: release-notes\ndescription: Use when generating massCode release notes for a GitHub release. Writes the notes to a gitignored file `docs/releases/<tag>.md` for the user to paste into the GitHub release. Use when summarizing merged PRs of a version into a consistent release notes structure.\n---\n\n# Release Notes\n\n## Overview\n\nЭтот skill генерирует release notes одного релиза `vX.Y.Z` для вставки в GitHub release. Цель — единая повторяемая структура от релиза к релизу.\n\nНе трогай `docs/website/download/latest-release.md` — это отдельная repo-страница со своим форматом.\n\n## Source Of Truth\n\n- Содержимое выводи из merged PR между предыдущим и новым тегом, не из памяти.\n- Список изменений бери так:\n  `git log --first-parent --oneline <prev-tag>..<new-tag>` (например `v5.5.0..v5.6.0`).\n- Если новый тег ещё не создан, используй `<prev-tag>..HEAD` и спроси/подтверди номер новой версии.\n- Поведение значимых фич проверяй в коде или в `docs/website/documentation`, прежде чем формулировать, если оно неочевидно из заголовка PR.\n\n## Output\n\n- Записывай результат в файл `docs/releases/<new-tag>.md` (например `docs/releases/v5.6.0.md`). Папка `docs/releases` в `.gitignore`, это рабочий буфер, а не часть репозитория.\n- Пиши именно в файл, а не выводом в терминал: так пользователь копирует чистый markdown без переносов строк, которые добавляет терминал.\n- После записи коротко сообщи путь к файлу и при необходимости покажи итог. Не коммить файл.\n\n## Format\n\nФайл содержит один markdown-блок в этой структуре и порядке:\n\n```\n## <Feature Name>\n\n<1-2 абзаца: что это и что даёт пользователю.>\n\n## <Another Feature Name>\n\n<1-2 абзаца.>\n\n## Workflow Improvements\n\n- <мелкое улучшение>\n- <мелкое улучшение>\n\n## Fixes\n\n- <исправление>\n- <исправление>\n\n**Full Changelog**: https://github.com/massCodeIO/massCode/compare/<prev-tag>...<new-tag>\n```\n\nПравила структуры:\n\n- Начинай прямо с тематических `##`-разделов. Не добавляй заголовок версии `# vX.Y.Z` (его даёт сам GitHub release), frontmatter или `<AssetsDownload />` — это артефакты repo-страницы.\n- Один `##`-раздел на каждую значимую фичу или связную группу фич.\n- `## Workflow Improvements` и `## Fixes` включай только если для них есть содержимое.\n- Compare-ссылка всегда последней строкой, с актуальными предыдущим и новым тегами.\n\n## What To Include\n\n- User-facing изменения: новые spaces и фичи, заметные улучшения workflow, видимые исправления.\n- Крупную фичу выноси в отдельный `##`-раздел с 1-2 абзацами о пользе для пользователя.\n- Мелкие улучшения собирай в `## Workflow Improvements` буллетами.\n- Исправления собирай в `## Fixes` буллетами, по одному на исправление.\n\n## What To Omit\n\n- Чисто внутренние коммиты: `ci`, `build`, `chore`, рефакторинг, bump зависимостей, релизные служебные коммиты (`build: release vX.Y.Z`).\n- Исключение: выноси платформенные изменения, заметные пользователю (например code signing и notarization на macOS), в `## Workflow Improvements`.\n- Не описывай детали реализации; пиши о результате для пользователя.\n\n## Writing Style\n\n- Английский, спокойный фактический тон. Что делает фича и зачем она пользователю, без маркетинговых превосходных степеней.\n- Никаких em dash. Это общее правило репозитория.\n- Имена spaces пиши консистентно: `Code`, `Notes`, `Math Notebook`, `Drawings`, `HTTP`, `Tools`. Не смешивай `Code` и `Snippets` как имя пространства.\n- `snippet` — единица контента внутри пространства Code, а не имя пространства. В Fixes допустимо «snippet fences», «snippet sync», но пространство всё равно называется Code.\n- Code identifiers, расширения файлов и токены оборачивай в backticks (`` `.excalidraw` ``, `` `@` ``, `` `Esc` ``).\n- Shortcuts указывай как в интерфейсе; macOS и Windows/Linux варианты различай, если они отличаются.\n\n## Common Mistakes\n\n- Перечислять коммиты дословно вместо группировки в user-facing разделы.\n- Включать `ci` / `build` / `chore` шум, который не виден пользователю.\n- Добавлять `# vX.Y.Z`, frontmatter или `<AssetsDownload />` (это формат repo-страницы, а не GitHub release).\n- Выводить нотис простыней в терминал вместо файла `docs/releases/<new-tag>.md` (терминал ломает переносы строк при копировании).\n- Коммитить файл из `docs/releases` — это игнорируемый рабочий буфер.\n- Смешивать имена пространств (`Code` против `Snippets`) внутри одного документа.\n- Описывать детали реализации вместо пользы для пользователя.\n- Забыть обновить compare-ссылку на актуальные теги.\n- Использовать em dash вопреки правилу репозитория.\n",".agents/skills/electron-api-and-ipc/SKILL.md":"---\nname: electron-api-and-ipc\ndescription: Use when changing massCode API routes, DTOs, IPC handlers, Electron bridges, or any renderer-to-main communication and storage-access boundaries.\n---\n\n# Electron API And IPC\n\n## Overview\n\nВсе backend-возможности massCode живут в main process. Renderer получает доступ к данным и системным операциям только через Elysia API или IPC channels.\n\n## Renderer Access Rules\n\n- В renderer для данных используй `import { api } from '~/renderer/services/api'`.\n- В renderer для системных операций используй `ipc.invoke('channel:action', payload)`.\n- Electron API из renderer доступен только через `src/renderer/electron.ts`.\n- Никогда не импортируй storage internals или backend-модули напрямую в renderer.\n\n## New API Endpoints\n\nПри добавлении нового endpoint:\n\n1. создай DTO в `src/main/api/dto/`;\n2. добавь route в `src/main/api/routes/`;\n3. запусти `pnpm api:generate`, чтобы обновить клиент.\n\nНе оставляй API-клиент рассинхронизированным с route/DTO изменениями.\n\n## IPC Conventions\n\n- Для filesystem и system ops используй `ipc.invoke(...)`.\n- Каналы должны укладываться в семейства:\n  - `fs:*`\n  - `system:*`\n  - `db:*` — legacy или migration flows, не основной путь для новой функциональности\n  - `main-menu:*`\n  - `prettier:*`\n  - `spaces:*`\n  - `theme:*`\n\n## Good Boundaries\n\n- Renderer формирует intent и payload.\n- Main/API работает с данными приложения, файловой системой и system APIs.\n- Ответ возвращается обратно в renderer в виде DTO или IPC result, а не через shared mutable backend module.\n\n## Common Mistakes\n\n- Тянуть backend-модуль напрямую в renderer ради “удобства”.\n- Менять DTO/route без `pnpm api:generate`.\n- Добавлять system/file behavior в renderer вместо IPC handler.\n- Добавлять новые `db:*` flows там, где задача должна идти через текущую API/IPC модель приложения.\n- Создавать ad-hoc каналы, которые не укладываются в существующие channel families.\n",".agents/skills/documentation-workflow/SKILL.md":"---\nname: documentation-workflow\ndescription: Use when adding or updating massCode documentation, documenting a new feature, changing docs website pages, adding docs assets, updating the VitePress sidebar, or adding README feature mentions.\n---\n\n# Documentation Workflow\n\n## Overview\n\nДокументация massCode живёт в VitePress сайте в `docs/website/documentation`. README — это общий обзор проекта, а не источник детального описания фич.\n\n## Documentation Surfaces\n\n- Документация фич: `docs/website/documentation/**`\n- Sidebar документации: `docs/website/.vitepress/config.mts`\n- Assets документации: `docs/website/public/**`\n- Overview документации: `docs/website/documentation/index.md`\n- Overview проекта: `README.md`\n\n## Core Rules\n\n- Проверяй поведение фичи в коде или существующей документации; не документируй по памяти.\n- Используй `rg`, чтобы найти связанные страницы, скриншоты, shortcuts, labels и существующие формулировки.\n- Если целевая версия известна, используй именно её. Если версия неизвестна, не придумывай её.\n- Пользовательская документация сайта пишется на английском, в стиле существующих docs pages.\n- Добавляй или обновляй наиболее конкретную страницу в `docs/website/documentation`.\n- Для новых страниц используй frontmatter с `title` и `description`.\n- Добавляй страницу в `docs/website/.vitepress/config.mts` только если она должна появиться в навигации.\n- Ссылайся из `docs/website/documentation/index.md` только на широкие, cross-cutting фичи.\n- Пиши короткими task-oriented секциями. Предпочитай пользовательские флоу, а не детали реализации.\n- Shortcuts документируй через `<kbd>...</kbd>` и указывай macOS плюс Windows/Linux варианты, если они отличаются.\n\n## Version Availability\n\n- Перед добавлением или изменением `<AppVersion>` проверяй историю фичи в коде, документации или предыдущем релизном теге.\n- Считай `<AppVersion text=\">=x.y\" />` минимальной версией, где появилась ровно описываемая возможность, а не версией её последнего улучшения.\n- Ставь marker на уровне страницы или общего раздела только когда вся описываемая сущность впервые появилась в этой версии.\n- Если новый релиз расширяет существующую фичу, сохраняй её исходный marker или отсутствие marker, а новую версию указывай только у отдельного подпункта или предложения про улучшение.\n- Разделяй смешанное описание на базовую возможность и versioned enhancement, если общий marker создаёт впечатление, что старая возможность раньше была недоступна.\n- Не добавляй version marker для bugfix или внутренней переработки без нового пользовательского сценария. Локально отмечай изменение формата хранения, если оно влияет на совместимость.\n\nПример: если custom folder icons существуют с 3.7, а Emoji и Upload добавлены в 5.9, оставляй `>=3.7` у базовой возможности и ставь `>=5.9` только у подпункта про Emoji и Upload.\n\n## Documentation Weight\n\n- Перед созданием страницы или раздела оцени самостоятельность пользовательского сценария, количество шагов, настроек и ограничений.\n- Описывай мелкое одношаговое действие одной строкой или буллетом внутри существующего релевантного раздела.\n- Создавай отдельный раздел для самостоятельного workflow с несколькими шагами, вариантами, настройками или важными ограничениями.\n- Выбирай одно основное место для подробного описания cross-cutting фичи. В других страницах оставляй короткое упоминание или ссылку вместо повторения полного объяснения.\n- Оставляй bugfix, внутреннюю оптимизацию и implementation detail только в release notes, если они не меняют пользовательский сценарий или требования совместимости.\n\n## Callouts\n\n- Используй `warning` для риска потери данных, несовместимости, необратимого действия или существенного security-ограничения.\n- Используй `info` для автоматической миграции и неочевидного поведения, которое помогает правильно понять основной workflow.\n- Оставляй основные инструкции обычным текстом; callout должен выделять контекст или исключение, а не содержать весь сценарий.\n- Объединяй связанные риски в один callout и избегай нескольких соседних блоков, если их можно прочитать как одно сообщение.\n- Добавляй короткий предметный заголовок, например `::: warning Compatibility` или `::: info Automatic migration`.\n\n## VitePress Markdown Gotchas\n\n- VitePress компилирует markdown как Vue-компонент, поэтому `{{ ... }}` трактуется как Vue-интерполяция и **исчезает** из вывода.\n- Fenced-блоки (` ``` `) защищены автоматически — внутри них `{{var}}` рендерится буквально.\n- **Инлайн-код в backticks НЕ защищён**: `` `{{variables}}` `` отрендерится пустым. Чтобы вывести литеральные двойные фигурные скобки в тексте или таблице, оборачивай в `v-pre`:\n  `<code v-pre>{{variables}}</code>`\n- Это же касается любых других Vue-конструкций (`{{ }}`, директивы) в произвольном тексте страницы.\n\n## Images And Assets Rules\n\n- Картинки для docs клади в `docs/website/public`.\n- Ссылайся на картинки через `withBase`, например:\n  `<img :src=\"withBase('/feature.png')\">`\n- Если страница использует `withBase`, добавь соответствующий script block:\n  `import { withBase } from 'vitepress'`\n- Используй скриншоты только когда они реально объясняют фичу. Не добавляй декоративные изображения.\n\n## README Rules\n\n- Добавляй README-упоминания только для user-facing фич, которые важны на уровне общего обзора проекта.\n- Держи README copy коротким и product-level; подробное использование должно быть в `docs/website/documentation`.\n- Не пиши в README, когда фича была добавлена. Version availability должна жить в docs pages или release notes.\n- Не ставь новую фичу первой автоматически. Сохраняй текущую информационную архитектуру: сначала основные spaces/features, затем широкие workflow helpers, если пользователь не попросил иначе.\n\n## Validation\n\n- Запускай `git diff --check`.\n- Для изменений docs website запускай `pnpm -C docs/website build`.\n- Если нужно форматирование, ограничивай его изменёнными файлами и избегай широкого churn в config-файлах.\n- Не коммить без явной просьбы пользователя. Для commit или PR загружай `github-workflow`.\n\n## Common Mistakes\n\n- Добавлять README-only документацию для фичи, которой нужна настоящая docs page.\n- Забывать VitePress sidebar для новой страницы, которая должна быть в навигации.\n- Добавлять version availability в README.\n- Переносить `<AppVersion>` всего существующего раздела на версию, в которой фича лишь получила улучшение.\n- Создавать отдельный раздел для одношаговой мелкой фичи, которую достаточно упомянуть в существующем разделе.\n- Повторять полное описание cross-cutting фичи на нескольких страницах вместо одного основного места и коротких упоминаний.\n- Использовать callout для обычной инструкции без риска, совместимости или неочевидного поведения.\n- Документировать shortcuts или поведение без проверки реализации.\n- Запускать широкие formatters, которые переписывают существующий стиль docs config.\n- Писать литеральные `{{ ... }}` в инлайн-коде без `v-pre` — VitePress съест их как Vue-интерполяцию.\n"},"items":[{"name":"AGENTS.md","path":"AGENTS.md","title":"AGENTS.md","content":"# Точка входа для агента massCode\n\nОтвечай всегда на русском.\n\nmassCode — это приложение на Electron + Vue 3 + TypeScript с TailwindCSS v4 в renderer, API-маршрутами на Elysia в main process, markdown vault как основным хранилищем пользовательского контента в v5 и `store.app` / `store.preferences` для локального UI state и настроек.\n\n## Всегда действующие правила\n\n- Следуй YAGNI. Предпочитай минимальную корректную реализацию вместо спекулятивных абстракций.\n- Соблюдай границы слоёв: renderer не должен напрямую обращаться к Node.js, filesystem или DB. Используй API или IPC.\n- Никогда не хардкодь пользовательские строки. Используй систему локализации.\n- Не запускай lint или тесты по всему проекту для локальной задачи. Ограничивай команды затронутыми файлами или директориями.\n- После изменений API DTO или routes запускай `pnpm api:generate`.\n- После изменений locale-файлов запускай `pnpm i18n:copy`.\n- Если задача совпадает по теме с одним из skills ниже, загружай этот skill до внесения изменений.\n\n## Skills\n\n- `.agents/skills/architecture-standards/SKILL.md`\n  Используй первым для общих правил репозитория: архитектура, naming, декомпозиция и выбор следующего skill.\n- `.agents/skills/vue-renderer-standards/SKILL.md`\n  Используй для работы с Vue renderer: `<script setup lang=\"ts\">`, правила auto-import, composables, shared state и renderer-side паттерны.\n- `.agents/skills/ui-foundations/SKILL.md`\n  Используй для базовых UI-правил: Tailwind v4, typography через `UiText` и согласованных styling decisions для renderer UI.\n- `.agents/skills/ui-primitives/SKILL.md`\n  Используй для component-level UI работы: `Ui*` components, Shadcn imports, `cn`, `cva`, notifications и правил против переизобретения primitives.\n- `.agents/skills/electron-api-and-ipc/SKILL.md`\n  Используй для API routes, DTO, IPC handlers, renderer-to-main communication и границ Electron-интеграции.\n- `.agents/skills/api-and-typing/SKILL.md`\n  Используй для generated API types, DTO-derived renderer typing и решения, когда локальный UI type оправдан, а когда нужно переиспользовать существующие API types.\n- `.agents/skills/spaces-architecture/SKILL.md`\n  Используй при изменениях, связанных с `code` / `notes` / `math` / `tools`, markdown-space state, sync behavior или `spaces:*` IPC.\n- `.agents/skills/i18n/SKILL.md`\n  Используй для правил локализации, размещения locale keys, `i18n.t(...)` и требования не хардкодить строки.\n- `.agents/skills/documentation-workflow/SKILL.md`\n  Используй для добавления или обновления документации, страниц `docs/website/documentation`, sidebar, assets и README-упоминаний фич.\n- `.agents/skills/release-notes/SKILL.md`\n  Используй для генерации release notes нового релиза в игнорируемый файл `docs/releases/<tag>.md` для вставки в GitHub release: группировка merged PR в user-facing разделы и compare-ссылка.\n- `.agents/skills/development-workflow/SKILL.md`\n  Используй для repo-specific workflow rules: scoped lint/test команды и обязательные follow-up шаги после изменений source-of-truth файлов.\n- `.agents/skills/github-workflow/SKILL.md`\n  Используй для massCode git и GitHub workflow: issue, ветки, commits, PR и подготовки к merge.\n\n## Рекомендуемый порядок загрузки\n\n- Широкая или неочевидная задача: начни с `architecture-standards`, затем загрузи профильный skill.\n- Renderer UI задача: `architecture-standards` → `vue-renderer-standards` → `ui-foundations` → `ui-primitives`.\n- API / IPC / Electron задача: `architecture-standards` → `electron-api-and-ipc`.\n- Generated types / renderer typing задача: `architecture-standards` → `api-and-typing`.\n- Spaces задача: `architecture-standards` → `spaces-architecture`.\n- Задача про текст и локализацию: `i18n`.\n- Задача про документацию или README: `documentation-workflow`.\n- Задача про release notes нового релиза: `release-notes`.\n- Workflow-чувствительная задача: `development-workflow`.\n- Задача про git / branch / commit / PR: `github-workflow`.\n\n## Основной стек\n\n- Framework: Vue 3, Composition API, `<script setup lang=\"ts\">`\n- Styling: TailwindCSS v4, `tailwind-merge`, `cva`\n- UI: локальные `src/renderer/components/ui`, Shadcn поверх `reka-ui`, `lucide-vue-next`\n- State: composables, без Pinia/Vuex\n- Backend: Electron main, Elysia API, markdown vault для контента и `electron-store` для локального состояния приложения\n- Utilities: `@vueuse/core`, `vue-sonner`\n","category":"root","tokens":1090},{"name":"SKILL.md","path":".agents/skills/vue-renderer-standards/SKILL.md","title":"vue-renderer-standards Skill","content":"---\nname: vue-renderer-standards\ndescription: Use when editing massCode renderer code in Vue 3, especially for script setup patterns, import rules, composables, shared state, and renderer-side conventions.\n---\n\n# Vue Renderer Standards\n\n## Overview\n\nRenderer в massCode строится на Vue 3 Composition API с `<script setup lang=\"ts\">`. Здесь важны строгие import rules, composable-first state sharing и запрет на прямой доступ к backend-возможностям.\n\n## Component Pattern\n\n- Используй Vue 3 Composition API и `<script setup lang=\"ts\">`.\n- Vue core (`ref`, `computed`, `watch`, `onMounted` и подобные) не импортируй вручную: они auto-imported.\n- Проектные компоненты из `src/renderer/components/` тоже не импортируй вручную: они auto-imported.\n- Локальную логику компонента держи в script, а не в template.\n\n## Manual Imports Only Where Required\n\nВсегда импортируй вручную:\n\n- composables из `@/composables`;\n- utils из `@/utils`;\n- `@vueuse/core`;\n- Electron bridge из `@/electron`;\n- Shadcn UI из `@/components/ui/shadcn/*`.\n\n## Shared State\n\n- Глобальное shared state реализуется composables без Pinia/Vuex.\n- Reactive state, который должен шариться между компонентами, объявляй на module level, вне экспортируемой функции composable.\n- Persistent UI/settings state храни через `store` из `@/electron`:\n  - `store.app` для UI state;\n  - `store.preferences` для user preferences.\n\n## VueUse First\n\n- Перед написанием нового composable сначала проверь, нет ли подходящего решения в `@vueuse/core`.\n- Кастомный composable добавляй только если готового utility реально нет.\n\n## Renderer Boundaries\n\n- Renderer не импортирует storage internals или backend-модули доступа к данным напрямую.\n- Renderer не обращается напрямую к Node.js, filesystem или storage runtime.\n- Доступ к main process возможен только через `api` или `ipc`.\n\n## Common Mistakes\n\n- Ручной импорт `ref` / `computed` / `watch`.\n- Ручной импорт локальных project components.\n- Локальный state внутри composable, который должен быть общим между несколькими компонентами.\n- Попытка “срезать путь” и импортировать backend-модуль прямо в renderer.\n","category":".agents","tokens":527},{"name":"SKILL.md","path":".agents/skills/ui-foundations/SKILL.md","title":"ui-foundations Skill","content":"---\nname: ui-foundations\ndescription: Use when defining or reviewing massCode UI foundation rules such as typography, renderer styling consistency, TailwindCSS v4 usage, and when raw markup starts competing with established UI text patterns.\n---\n\n# UI Foundations\n\n## Overview\n\nUI в massCode должен оставаться визуально консистентным. Этот skill отвечает за базовые styling decisions: как относиться к typography, когда использовать established text patterns и как не скатываться в разрозненный renderer styling.\n\n## Core Rules\n\n- Базовая styling system в renderer строится на TailwindCSS v4.\n- Новые UI-экраны и состояния должны продолжать существующий visual language, а не вводить локальные правила “для одного места”.\n- Для стандартного app UI предпочитай семантические токены вроде `bg-background`, `text-muted-foreground`, `border-border`, `border-destructive/*` вместо raw palette-классов вроде `bg-white`, `text-black`, `text-green-500`, `bg-slate-900`.\n- Typography по умолчанию строится через `UiText`.\n- Не заменяй `UiText` на произвольный набор `text-*`, `font-*`, `text-muted-foreground`, если подходящий variant уже существует.\n- Если `UiText` почти подходит, лучше добавить точечные классы поверх него, чем уходить в raw typography markup.\n\n## Typography\n\n- `UiText` — базовый источник правды для текстовых размеров и muted-state.\n- `caption` и `xs` — подписи, helper text, secondary labels.\n- `sm` и `base` — основной интерфейсный текст.\n- `lg` и `xl` — усиленные title/value cases, когда это действительно нужно по hierarchy.\n- `font-mono` — только для code-like content, IDs, counts with alignment needs, readonly generated output и подобных случаев.\n- Для uppercase labels используй существующий pattern через `UiText` или согласованный tracking/uppercase стиль, а не случайную смесь utility classes в каждом месте.\n\n## Spacing And Layout Rhythm\n\n- Корневые screen/container wrappers обычно живут в ритме `space-y-4` или `space-y-6`.\n- Внутри компактных секций чаще всего `space-y-2` или `space-y-3`.\n- Grid gaps по умолчанию: `gap-2`, `gap-3`, `gap-4` в зависимости от плотности.\n- Не придумывай локальный spacing-scale для одного экрана, если существующие интервалы уже покрывают задачу.\n- Повторяющиеся content blocks должны иметь одинаковый padding и vertical rhythm.\n\n## Radius And Shadows\n\n- `rounded-md` — controls, inline boxes, compact containers.\n- `rounded-lg` — card-like blocks, dialogs, overlays, dashboard sections.\n- `rounded-xl` — preview-heavy surfaces и крупные visual blocks.\n- `rounded-full` — pills, badges, circular handles.\n- `shadow-xs` — inputs, buttons, small controls.\n- `shadow-md` и `shadow-lg` — overlays, popovers, previews, где elevation реально нужна.\n- Не вводи произвольные `rounded-[...]` и `shadow-[...]`, если стандартные токены уже подходят.\n\n## Exceptions\n\n- Raw colors допустимы, если цвет является частью самих данных или preview:\n  color pickers, contrast previews, code/image export backgrounds, diagram or visualizer nodes.\n- Если цвет вычисляется из контента или нужен для корректного контраста на пользовательском фоне, raw class или inline style допустимы.\n- Исключения не должны становиться поводом тащить raw palette в обычный application chrome.\n\n## When To Prefer This Skill\n\n- Нужно понять, как оформлять текст и подписи в новом UI.\n- Есть соблазн писать raw Tailwind typography вместо существующего text pattern.\n- В экране начинают появляться локальные styling rules, которые расходятся с остальным renderer UI.\n- Нужно принять решение на уровне визуальной базы, а не конкретного button/input/dialog.\n\n## Common Mistakes\n\n- Размазывать локальные визуальные исключения по фичам.\n- Тащить raw palette в обычный app UI без реальной причины.\n- Писать текст напрямую через произвольные utility classes там, где подходит `UiText`.\n- Делать новый экран со своим spacing rhythm вместо существующего scale.\n- Случайно смешивать small-control radii и preview-surface radii в одном и том же UI слое.\n- Считать Tailwind поводом делать каждый экран визуально “с нуля”.\n","category":".agents","tokens":1008},{"name":"SKILL.md","path":".agents/skills/ui-primitives/SKILL.md","title":"ui-primitives Skill","content":"---\nname: ui-primitives\ndescription: Use when building or refactoring massCode UI components with local Ui primitives or Shadcn, especially for cn, cva, notifications, and rules against reimplementing basic controls.\n---\n\n# UI Primitives\n\n## Overview\n\nБазовые UI-элементы в massCode должны собираться из существующих `Ui*` компонентов и Shadcn-паттернов. Этот skill отвечает за component-level usage rules, а не за общую визуальную базу.\n\n## Component Usage\n\n- Локальные UI-компоненты доступны через auto-import с префиксом `Ui`.\n- Базовые элементы вроде button, input, checkbox, action button не переизобретай на сыром HTML, если есть готовый `Ui*` вариант.\n- Если нужного элемента нет, сначала создай его в `src/renderer/components/ui/`, потом используй в фиче.\n\n## Buttons\n\n- Primary action должен быть явным и не конкурировать с несколькими равноправными CTA в одном контейнере.\n- Icon-only actions должны быть понятны по контексту и иметь tooltip или другой доступный label path.\n- Loading и pending actions должны использовать существующий button pattern, а не ad-hoc “disabled text swap”.\n- Destructive actions не должны выглядеть как обычные secondary controls.\n\n## Cards And Containers\n\n- Для автономных panel-like блоков используй существующий `Card` / `Ui*` container pattern, если он уже есть в области.\n- Внутренние muted blocks не нужно пересобирать разными `div`-паттернами в каждой фиче.\n- Repeated panel structure должна переезжать в shared primitive или local feature primitive, а не копироваться markup-в-маркап.\n\n## Readonly And Copyable Content\n\n- Длинный readonly output, generated text, URLs и similar content не показывай как “обычный disabled input”, если это ухудшает чтение.\n- Для copy flows используй существующий copy pattern и уведомления через `useSonner()`.\n- Readonly content должен оставаться визуально читаемым и удобно копируемым.\n\n## Styling Helpers\n\n- Для variants используй `cva`.\n- Для склейки классов используй `cn()`.\n- Не делай variants вручную строковыми `if`-цепочками там, где нужен нормальный variant API.\n\n## Shadcn Rules\n\n- Shadcn-компоненты импортируй вручную из `@/components/ui/shadcn/*`.\n- Для namespace-based компонентов используй паттерн вроде `import * as Dialog from '@/components/ui/shadcn/dialog'`.\n\n## Notifications\n\n- Для уведомлений используй `useSonner()`.\n- Не добавляй локальную, параллельную систему toast/notification внутри фичи.\n\n## Tooltip, Popover, Overlay\n\n- Tooltip — для короткого пояснения.\n- Popover — для richer inline content, picker-like content или contextual controls.\n- Не заменяй их ad-hoc overlay-разметкой без необходимости.\n- Validation и inline guidance должны использовать существующие tooltip/popover primitives, если проект уже их применяет в аналогичных местах.\n\n## Common Mistakes\n\n- Писать ещё одну кнопку или input с нуля “потому что быстрее”.\n- Склеивать сложные conditional classes без `cn()`.\n- Дублировать существующий primitive внутри feature directory вместо общего `src/renderer/components/ui/`.\n- Использовать disabled input как универсальный readonly display surface.\n- Делать overlay pattern вручную там, где уже есть Shadcn primitive.\n- Смешивать правила primitives с вопросами визуальной базы, которые должны идти в `ui-foundations`.\n","category":".agents","tokens":810},{"name":"SKILL.md","path":".agents/skills/i18n/SKILL.md","title":"i18n Skill","content":"---\nname: i18n\ndescription: Use when changing massCode localization, adding user-facing strings, creating locale keys, or wiring text through the project's translation system.\n---\n\n# I18n\n\n## Overview\n\nВ massCode новый пользовательский текст всегда проходит через localization system. Базовым source of truth для новых ключей считается английская локаль.\n\n## Localization Rules\n\n- Базовый язык проекта — English.\n- `en_US` остаётся базовым source of truth для новых ключей.\n- Все новые ключи сначала добавляй в `src/main/i18n/locales/en_US/`.\n- При добавлении нового ключа сразу добавляй его и в русскую локаль, чтобы `ru_RU` не отставала от базового английского набора.\n- Не хардкодь user-facing strings ни в template, ни в script logic.\n- Используй `i18n.t('namespace:key.path')` или сокращённый `i18n.t('key.path')` для default `ui` namespace.\n- Импорт `i18n` делай из `@/electron`.\n\n## After Locale Changes\n\n- После добавления или изменения locale keys запускай `pnpm i18n:copy`.\n- Не оставляй `en_US` и `ru_RU` в несинхронном состоянии.\n- Остальные локали могут догоняться отдельно контрибьюторами и не считаются обязательным блокером для каждой локальной правки.\n\n## Common Mistakes\n\n- Хардкодить новый текст “временно”.\n- Добавлять ключи не в `en_US`, а сразу в другой locale.\n- Обновить `en_US`, но забыть сразу добавить тот же ключ в `ru_RU`.\n- Использовать текст напрямую в template, хотя это часть UI.\n- Забывать `pnpm i18n:copy` после изменения locale source-of-truth.\n","category":".agents","tokens":371},{"name":"SKILL.md","path":".agents/skills/github-workflow/SKILL.md","title":"github-workflow Skill","content":"---\nname: github-workflow\ndescription: Use when working with massCode issues, branches, commits, pull requests, or merge preparation in GitHub.\n---\n\n# github-workflow\n\n## Issue\n\nЕсли работа идёт по issue, читать его через `gh`:\n\n```bash\ngh issue view <number> -R massCodeIO/massCode\n```\n\nЕсли issue описывает bug, не считай его автоматически подтверждённым.\n\nСначала:\n\n1. понять ожидаемое поведение;\n2. проверить текущее поведение в коде или воспроизвести проблему;\n3. подтвердить bug или явно зафиксировать, что он не подтверждается;\n4. только после этого переходить к ветке, фиксу и PR.\n\nЕсли bug не воспроизводится или issue описан неясно:\n\n- не начинать слепую реализацию;\n- сначала сообщить, что проблема не подтверждена, и уточнить условия или шаги воспроизведения.\n\n## Branch\n\nСоздавай ветку от `main` с префиксом по типу изменения (`feat/`, `fix/`, `chore/`, `refactor/`) и коротким описанием. Если работа идёт по issue — уместно добавить номер в конец.\n\n```bash\ngit checkout main && git pull\ngit checkout -b feat/<short-description> main\n```\n\n## PR\n\nЗаголовок PR — conventional commits:\n\n```text\ntype: description\n```\n\nПеред созданием PR предложи заголовок пользователю на подтверждение.\n\nЕсли PR закрывает существующий issue, в описании добавляй:\n\n```text\ncloses #123\n```\n\nПеред PR убедись, что релевантные проверки и тесты для затронутой области действительно прогнаны.\n\nСоздание:\n\n```bash\ngh pr create \\\n  --base main \\\n  --head <branch-name> \\\n  --title \"type: description\" \\\n  --body \"closes #<issue_number>\" \\\n  --assignee @me\n```\n\nЕсли issue нет — в `--body` кратко опиши суть изменений без служебного AI-хвоста.\n\nПосле создания PR предложи пользователю смерджить его в `main`:\n\n```bash\ngh pr merge <pr_number> -R massCodeIO/massCode --squash --delete-branch\n```\n\nПосле merge синхронизируй локальную ветку:\n\n```bash\ngit checkout main && git pull\ngit branch -d <branch-name>\n```\n\n## Commit\n\n- Только однострочный заголовок conventional commit.\n- Используй подходящий scope для коммитов и PR (`feat(notes):`, 'fix(math):).\n- Без тела, без `Co-Authored-By`.\n","category":".agents","tokens":518},{"name":"SKILL.md","path":".agents/skills/spaces-architecture/SKILL.md","title":"spaces-architecture Skill","content":"---\nname: spaces-architecture\ndescription: Use when working on massCode spaces such as code, notes, math, or tools, especially when changing their state, behavior, synchronization, or spaces IPC channels.\n---\n\n# Spaces Architecture\n\n## Overview\n\nmassCode использует систему Spaces для разделения функциональных областей. Это не просто UI tabs: у каждого space есть собственное состояние, свои правила обновления и свой способ синхронизации с данными в vault.\n\n## Space Model\n\n- `code` — snippets, folders, tags\n- `notes` — notes, folders, tags, markdown-based flows\n- `math` — calculation sheets и состояние math notebook\n- `tools` — developer utilities\n\nОсновные определения живут в `src/renderer/spaceDefinitions.ts`.\n\n## Space State Storage\n\n- Состояние каждого space хранится в `__spaces__/{spaceId}/.state.yaml` внутри vault.\n- Runtime helpers:\n  - `src/main/storage/providers/markdown/runtime/spaces.ts`\n  - `src/main/storage/providers/markdown/runtime/spaceState.ts`\n- Директория `__spaces__/` — служебная часть vault для состояния spaces.\n\n## Persistence Rules\n\n- Запись состояния spaces использует ту же debounce/flush инфраструктуру, что и `state.json`.\n- Не ломай совместимость с `pendingStateWriteByPath` и flush-on-exit поведением.\n- Если меняешь способ записи, учитывай сценарий завершения приложения до явного ручного flush.\n\n## IPC Rules\n\n- Space-specific IPC handlers живут в `src/main/ipc/handlers/spaces.ts`.\n- Текущие math handlers:\n  - `spaces:math:read`\n  - `spaces:math:write`\n- Если добавляется новый `spaces:*` flow, он должен работать через общую модель состояния spaces, а не в обход неё.\n\n## Space-Aware Sync\n\n- `system:storage-synced` обновляет активное пространство через `getActiveSpaceId()`.\n- Ожидаемое поведение:\n  - `code` → refresh folders + snippets\n  - `notes` → refresh notes + note folders\n  - `math` → `reloadFromDisk()` через `useMathNotebook()`\n  - `tools` → no-op\n- Изменения, которые уже сохранены в vault, должны вызывать `markPersistedStorageMutation()`, чтобы не создавать sync loops.\n\n## Common Mistakes\n\n- Считать spaces только UI-концепцией и забывать, что у них есть собственное состояние и правила синхронизации.\n- Писать состояние space в обход общих markdown runtime helpers.\n- Добавлять mutation без `markPersistedStorageMutation()`.\n- Ломать согласованность между состоянием space, helpers и sync behavior.\n","category":".agents","tokens":591},{"name":"SKILL.md","path":".agents/skills/release-notes/SKILL.md","title":"release-notes Skill","content":"---\nname: release-notes\ndescription: Use when generating massCode release notes for a GitHub release. Writes the notes to a gitignored file `docs/releases/<tag>.md` for the user to paste into the GitHub release. Use when summarizing merged PRs of a version into a consistent release notes structure.\n---\n\n# Release Notes\n\n## Overview\n\nЭтот skill генерирует release notes одного релиза `vX.Y.Z` для вставки в GitHub release. Цель — единая повторяемая структура от релиза к релизу.\n\nНе трогай `docs/website/download/latest-release.md` — это отдельная repo-страница со своим форматом.\n\n## Source Of Truth\n\n- Содержимое выводи из merged PR между предыдущим и новым тегом, не из памяти.\n- Список изменений бери так:\n  `git log --first-parent --oneline <prev-tag>..<new-tag>` (например `v5.5.0..v5.6.0`).\n- Если новый тег ещё не создан, используй `<prev-tag>..HEAD` и спроси/подтверди номер новой версии.\n- Поведение значимых фич проверяй в коде или в `docs/website/documentation`, прежде чем формулировать, если оно неочевидно из заголовка PR.\n\n## Output\n\n- Записывай результат в файл `docs/releases/<new-tag>.md` (например `docs/releases/v5.6.0.md`). Папка `docs/releases` в `.gitignore`, это рабочий буфер, а не часть репозитория.\n- Пиши именно в файл, а не выводом в терминал: так пользователь копирует чистый markdown без переносов строк, которые добавляет терминал.\n- После записи коротко сообщи путь к файлу и при необходимости покажи итог. Не коммить файл.\n\n## Format\n\nФайл содержит один markdown-блок в этой структуре и порядке:\n\n```\n## <Feature Name>\n\n<1-2 абзаца: что это и что даёт пользователю.>\n\n## <Another Feature Name>\n\n<1-2 абзаца.>\n\n## Workflow Improvements\n\n- <мелкое улучшение>\n- <мелкое улучшение>\n\n## Fixes\n\n- <исправление>\n- <исправление>\n\n**Full Changelog**: https://github.com/massCodeIO/massCode/compare/<prev-tag>...<new-tag>\n```\n\nПравила структуры:\n\n- Начинай прямо с тематических `##`-разделов. Не добавляй заголовок версии `# vX.Y.Z` (его даёт сам GitHub release), frontmatter или `<AssetsDownload />` — это артефакты repo-страницы.\n- Один `##`-раздел на каждую значимую фичу или связную группу фич.\n- `## Workflow Improvements` и `## Fixes` включай только если для них есть содержимое.\n- Compare-ссылка всегда последней строкой, с актуальными предыдущим и новым тегами.\n\n## What To Include\n\n- User-facing изменения: новые spaces и фичи, заметные улучшения workflow, видимые исправления.\n- Крупную фичу выноси в отдельный `##`-раздел с 1-2 абзацами о пользе для пользователя.\n- Мелкие улучшения собирай в `## Workflow Improvements` буллетами.\n- Исправления собирай в `## Fixes` буллетами, по одному на исправление.\n\n## What To Omit\n\n- Чисто внутренние коммиты: `ci`, `build`, `chore`, рефакторинг, bump зависимостей, релизные служебные коммиты (`build: release vX.Y.Z`).\n- Исключение: выноси платформенные изменения, заметные пользователю (например code signing и notarization на macOS), в `## Workflow Improvements`.\n- Не описывай детали реализации; пиши о результате для пользователя.\n\n## Writing Style\n\n- Английский, спокойный фактический тон. Что делает фича и зачем она пользователю, без маркетинговых превосходных степеней.\n- Никаких em dash. Это общее правило репозитория.\n- Имена spaces пиши консистентно: `Code`, `Notes`, `Math Notebook`, `Drawings`, `HTTP`, `Tools`. Не смешивай `Code` и `Snippets` как имя пространства.\n- `snippet` — единица контента внутри пространства Code, а не имя пространства. В Fixes допустимо «snippet fences», «snippet sync», но пространство всё равно называется Code.\n- Code identifiers, расширения файлов и токены оборачивай в backticks (`` `.excalidraw` ``, `` `@` ``, `` `Esc` ``).\n- Shortcuts указывай как в интерфейсе; macOS и Windows/Linux варианты различай, если они отличаются.\n\n## Common Mistakes\n\n- Перечислять коммиты дословно вместо группировки в user-facing разделы.\n- Включать `ci` / `build` / `chore` шум, который не виден пользователю.\n- Добавлять `# vX.Y.Z`, frontmatter или `<AssetsDownload />` (это формат repo-страницы, а не GitHub release).\n- Выводить нотис простыней в терминал вместо файла `docs/releases/<new-tag>.md` (терминал ломает переносы строк при копировании).\n- Коммитить файл из `docs/releases` — это игнорируемый рабочий буфер.\n- Смешивать имена пространств (`Code` против `Snippets`) внутри одного документа.\n- Описывать детали реализации вместо пользы для пользователя.\n- Забыть обновить compare-ссылку на актуальные теги.\n- Использовать em dash вопреки правилу репозитория.\n","category":".agents","tokens":1119},{"name":"SKILL.md","path":".agents/skills/electron-api-and-ipc/SKILL.md","title":"electron-api-and-ipc Skill","content":"---\nname: electron-api-and-ipc\ndescription: Use when changing massCode API routes, DTOs, IPC handlers, Electron bridges, or any renderer-to-main communication and storage-access boundaries.\n---\n\n# Electron API And IPC\n\n## Overview\n\nВсе backend-возможности massCode живут в main process. Renderer получает доступ к данным и системным операциям только через Elysia API или IPC channels.\n\n## Renderer Access Rules\n\n- В renderer для данных используй `import { api } from '~/renderer/services/api'`.\n- В renderer для системных операций используй `ipc.invoke('channel:action', payload)`.\n- Electron API из renderer доступен только через `src/renderer/electron.ts`.\n- Никогда не импортируй storage internals или backend-модули напрямую в renderer.\n\n## New API Endpoints\n\nПри добавлении нового endpoint:\n\n1. создай DTO в `src/main/api/dto/`;\n2. добавь route в `src/main/api/routes/`;\n3. запусти `pnpm api:generate`, чтобы обновить клиент.\n\nНе оставляй API-клиент рассинхронизированным с route/DTO изменениями.\n\n## IPC Conventions\n\n- Для filesystem и system ops используй `ipc.invoke(...)`.\n- Каналы должны укладываться в семейства:\n  - `fs:*`\n  - `system:*`\n  - `db:*` — legacy или migration flows, не основной путь для новой функциональности\n  - `main-menu:*`\n  - `prettier:*`\n  - `spaces:*`\n  - `theme:*`\n\n## Good Boundaries\n\n- Renderer формирует intent и payload.\n- Main/API работает с данными приложения, файловой системой и system APIs.\n- Ответ возвращается обратно в renderer в виде DTO или IPC result, а не через shared mutable backend module.\n\n## Common Mistakes\n\n- Тянуть backend-модуль напрямую в renderer ради “удобства”.\n- Менять DTO/route без `pnpm api:generate`.\n- Добавлять system/file behavior в renderer вместо IPC handler.\n- Добавлять новые `db:*` flows там, где задача должна идти через текущую API/IPC модель приложения.\n- Создавать ad-hoc каналы, которые не укладываются в существующие channel families.\n","category":".agents","tokens":480},{"name":"SKILL.md","path":".agents/skills/documentation-workflow/SKILL.md","title":"documentation-workflow Skill","content":"---\nname: documentation-workflow\ndescription: Use when adding or updating massCode documentation, documenting a new feature, changing docs website pages, adding docs assets, updating the VitePress sidebar, or adding README feature mentions.\n---\n\n# Documentation Workflow\n\n## Overview\n\nДокументация massCode живёт в VitePress сайте в `docs/website/documentation`. README — это общий обзор проекта, а не источник детального описания фич.\n\n## Documentation Surfaces\n\n- Документация фич: `docs/website/documentation/**`\n- Sidebar документации: `docs/website/.vitepress/config.mts`\n- Assets документации: `docs/website/public/**`\n- Overview документации: `docs/website/documentation/index.md`\n- Overview проекта: `README.md`\n\n## Core Rules\n\n- Проверяй поведение фичи в коде или существующей документации; не документируй по памяти.\n- Используй `rg`, чтобы найти связанные страницы, скриншоты, shortcuts, labels и существующие формулировки.\n- Если целевая версия известна, используй именно её. Если версия неизвестна, не придумывай её.\n- Пользовательская документация сайта пишется на английском, в стиле существующих docs pages.\n- Добавляй или обновляй наиболее конкретную страницу в `docs/website/documentation`.\n- Для новых страниц используй frontmatter с `title` и `description`.\n- Добавляй страницу в `docs/website/.vitepress/config.mts` только если она должна появиться в навигации.\n- Ссылайся из `docs/website/documentation/index.md` только на широкие, cross-cutting фичи.\n- Пиши короткими task-oriented секциями. Предпочитай пользовательские флоу, а не детали реализации.\n- Shortcuts документируй через `<kbd>...</kbd>` и указывай macOS плюс Windows/Linux варианты, если они отличаются.\n\n## Version Availability\n\n- Перед добавлением или изменением `<AppVersion>` проверяй историю фичи в коде, документации или предыдущем релизном теге.\n- Считай `<AppVersion text=\">=x.y\" />` минимальной версией, где появилась ровно описываемая возможность, а не версией её последнего улучшения.\n- Ставь marker на уровне страницы или общего раздела только когда вся описываемая сущность впервые появилась в этой версии.\n- Если новый релиз расширяет существующую фичу, сохраняй её исходный marker или отсутствие marker, а новую версию указывай только у отдельного подпункта или предложения про улучшение.\n- Разделяй смешанное описание на базовую возможность и versioned enhancement, если общий marker создаёт впечатление, что старая возможность раньше была недоступна.\n- Не добавляй version marker для bugfix или внутренней переработки без нового пользовательского сценария. Локально отмечай изменение формата хранения, если оно влияет на совместимость.\n\nПример: если custom folder icons существуют с 3.7, а Emoji и Upload добавлены в 5.9, оставляй `>=3.7` у базовой возможности и ставь `>=5.9` только у подпункта про Emoji и Upload.\n\n## Documentation Weight\n\n- Перед созданием страницы или раздела оцени самостоятельность пользовательского сценария, количество шагов, настроек и ограничений.\n- Описывай мелкое одношаговое действие одной строкой или буллетом внутри существующего релевантного раздела.\n- Создавай отдельный раздел для самостоятельного workflow с несколькими шагами, вариантами, настройками или важными ограничениями.\n- Выбирай одно основное место для подробного описания cross-cutting фичи. В других страницах оставляй короткое упоминание или ссылку вместо повторения полного объяснения.\n- Оставляй bugfix, внутреннюю оптимизацию и implementation detail только в release notes, если они не меняют пользовательский сценарий или требования совместимости.\n\n## Callouts\n\n- Используй `warning` для риска потери данных, несовместимости, необратимого действия или существенного security-ограничения.\n- Используй `info` для автоматической миграции и неочевидного поведения, которое помогает правильно понять основной workflow.\n- Оставляй основные инструкции обычным текстом; callout должен выделять контекст или исключение, а не содержать весь сценарий.\n- Объединяй связанные риски в один callout и избегай нескольких соседних блоков, если их можно прочитать как одно сообщение.\n- Добавляй короткий предметный заголовок, например `::: warning Compatibility` или `::: info Automatic migration`.\n\n## VitePress Markdown Gotchas\n\n- VitePress компилирует markdown как Vue-компонент, поэтому `{{ ... }}` трактуется как Vue-интерполяция и **исчезает** из вывода.\n- Fenced-блоки (` ``` `) защищены автоматически — внутри них `{{var}}` рендерится буквально.\n- **Инлайн-код в backticks НЕ защищён**: `` `{{variables}}` `` отрендерится пустым. Чтобы вывести литеральные двойные фигурные скобки в тексте или таблице, оборачивай в `v-pre`:\n  `<code v-pre>{{variables}}</code>`\n- Это же касается любых других Vue-конструкций (`{{ }}`, директивы) в произвольном тексте страницы.\n\n## Images And Assets Rules\n\n- Картинки для docs клади в `docs/website/public`.\n- Ссылайся на картинки через `withBase`, например:\n  `<img :src=\"withBase('/feature.png')\">`\n- Если страница использует `withBase`, добавь соответствующий script block:\n  `import { withBase } from 'vitepress'`\n- Используй скриншоты только когда они реально объясняют фичу. Не добавляй декоративные изображения.\n\n## README Rules\n\n- Добавляй README-упоминания только для user-facing фич, которые важны на уровне общего обзора проекта.\n- Держи README copy коротким и product-level; подробное использование должно быть в `docs/website/documentation`.\n- Не пиши в README, когда фича была добавлена. Version availability должна жить в docs pages или release notes.\n- Не ставь новую фичу первой автоматически. Сохраняй текущую информационную архитектуру: сначала основные spaces/features, затем широкие workflow helpers, если пользователь не попросил иначе.\n\n## Validation\n\n- Запускай `git diff --check`.\n- Для изменений docs website запускай `pnpm -C docs/website build`.\n- Если нужно форматирование, ограничивай его изменёнными файлами и избегай широкого churn в config-файлах.\n- Не коммить без явной просьбы пользователя. Для commit или PR загружай `github-workflow`.\n\n## Common Mistakes\n\n- Добавлять README-only документацию для фичи, которой нужна настоящая docs page.\n- Забывать VitePress sidebar для новой страницы, которая должна быть в навигации.\n- Добавлять version availability в README.\n- Переносить `<AppVersion>` всего существующего раздела на версию, в которой фича лишь получила улучшение.\n- Создавать отдельный раздел для одношаговой мелкой фичи, которую достаточно упомянуть в существующем разделе.\n- Повторять полное описание cross-cutting фичи на нескольких страницах вместо одного основного места и коротких упоминаний.\n- Использовать callout для обычной инструкции без риска, совместимости или неочевидного поведения.\n- Документировать shortcuts или поведение без проверки реализации.\n- Запускать широкие formatters, которые переписывают существующий стиль docs config.\n- Писать литеральные `{{ ... }}` в инлайн-коде без `v-pre` — VitePress съест их как Vue-интерполяцию.\n","category":".agents","tokens":1731}]}