dsh-desktop-kit 0.0.0-stage → 1.0.0

package/skills/project-memory-maintenance/SKILL.md

@@ -0,0 +1,170 @@
+---
+name: project-memory-maintenance
+description: "Правила ведения локальной памяти проектов через project_memory: журнал после каждой значимой сессии, обновление секций досье, дедупликация поиском, лимиты размера, свежесть INDEX.json."
+whenToUse: "После любой значимой сессии в проекте (до финального ответа), при изменении архитектуры, инвариантов или команд, при найденной ловушке, при устаревании досье и по просьбе «запомни это»."
+user-invocable: true
+---
+
+# PROJECT-MEMORY-MAINTENANCE — ведение памяти проекта
+
+> Память полезна, только если она актуальна, не дублируется и не превращается в свалку.
+> Хранилище локальное: `%USERPROFILE%\.dsh\projects-memory\<slug>\`.
+> Содержимое проекта не отправляется в сеть никогда.
+
+## 0. Контракт
+
+1. Журнал пишется **после каждой значимой сессии**, до финального ответа пользователю.
+2. В секции досье попадают только долговечные факты; ход работы — в журнал.
+3. Перед записью — `search`: дубликат дописывай в существующий пункт, а не создавай новый.
+4. В досье, журнале и `INDEX.json` нет секретов, PII, копий кода и дампов.
+5. Пиши только через `project_memory`; файлы хранилища руками не редактируй.
+
+## 1. API (кратко)
+
+Сигнатура: `project_memory(action, project?, file?, content?, query?, root?, name?, mode?, maxChars?)`.
+В текущей сборке инструмента у `register` есть также необязательный `stack`.
+Хранилище: `%USERPROFILE%\.dsh\projects-memory\<slug>\` — `PROJECT.md`, `ARCHITECTURE.md`, `CODE-MAP.md`, `INVARIANTS.md`, `GOTCHAS.md`, `RUNBOOK.md`, `JOURNAL/YYYY-MM.md`, `INDEX.json`.
+
+| action | Когда | Аргументы |
+|---|---|---|
+| `status` | в начале и в конце сессии | — |
+| `list` | если нужно найти проект | — |
+| `read` | перед правкой секции | `project`, `file`, `maxChars` |
+| `search` | перед любой записью (дедуп) | `project`, `query`, `maxChars` |
+| `append_journal` | после сессии | `project`, `content` |
+| `update_section` | долговечный факт | `project`, `file`, `content`, `mode` |
+| `register` | новый проект | `name`, `root` (+ `stack`) |
+
+- `file` — `PROJECT`, `ARCHITECTURE`, `CODE-MAP`, `INVARIANTS`, `GOTCHAS`, `RUNBOOK`, `JOURNAL`.
+- `mode` — `replace` (по умолчанию) или `append`.
+- `project` по умолчанию — проект текущей сессии; при работе с чужим проектом указывай slug явно.
+- `maxChars` ограничивает вывод `read` (500–30000, по умолчанию 12000); не выкачивай досье целиком без нужды.
+
+## 2. Что считать значимой сессией
+
+Да:
+- изменение кода/конфига/схемы данных;
+- архитектурное или продуктовое решение;
+- найденная и исправленная ошибка, подтверждённая проверкой;
+- новый инвариант или ловушка, которые должны пережить сессию;
+- деплой, откат, смена окружения или команд запуска;
+- глубокий анализ проекта (`project-deep-dive`).
+
+Нет:
+- тривиальный вопрос, чтение файла без выводов;
+- повторное обсуждение уже записанного;
+- неудачная попытка без нового знания.
+
+Сомневаешься — пиши короткую запись в журнал: лишняя строка дешевле потерянного знания.
+
+## 3. Журнал: когда и как
+
+Пиши `append_journal` в конце каждой значимой сессии (файл `JOURNAL/YYYY-MM.md` текущего месяца).
+Несколько связанных шагов в одной сессии — одна запись, а не десять.
+
+Точный шаблон записи:
+```markdown
+## YYYY-MM-DD — <краткое название сессии>
+- Что делали: ...
+- Что выявили: ...
+- Решения: ...
+- Проверки: ...
+- Осталось: ...
+```
+
+Правила:
+- Вызов: `project_memory(action="append_journal", project="<slug>", content="<запись>")`.
+- Все пять пунктов обязательны; если пункт пуст — пиши «нет», не удаляй его.
+- 1–3 строки на пункт; без копий кода, логов, дампов и пересказа чата.
+- «Что выявили» — факты, меняющие понимание проекта (причина, зависимость, ловушка).
+- «Проверки» — что реально запускалось и результат: тесты, линтер, сборка, ручной сценарий, тест на копии.
+- «Осталось» — конкретные следующие шаги или риски; «нет» допустимо.
+- Секреты и PII вырезай: «ошибка с `DB_PASSWORD` (значение не сохранено)».
+- Подробный шаблон и примеры — `references/journal-template.md`.
+
+## 4. Правила обновления секций
+
+| Секция | Обновляй, когда | Не пиши сюда |
+|---|---|---|
+| `PROJECT` | сменились стек, пути, прод, владелец, статус | историю сессий (это журнал) |
+| `ARCHITECTURE` | новые/удалённые компоненты, границы, потоки, внешние сервисы | детали реализации алгоритмов |
+| `CODE-MAP` | новый модуль, маршрут, точка входа; сдвинулись якоря | код целиком |
+| `INVARIANTS` | новое жёсткое правило, подтверждённое тестом или пользователем | советы и вкусовые предпочтения |
+| `GOTCHAS` | каждая неочевидная ловушка с симптомом | банальности «проверяй null» |
+| `RUNBOOK` | изменились команды, окружение, деплой, откат | объяснение архитектуры |
+| `JOURNAL` | каждая значимая сессия | дампы, секреты, чат |
+
+- `mode="append"` — добавляешь пункт; `mode="replace"` — перестраиваешь или чистишь секцию (сначала `read`).
+- Долговечный факт = верен через месяц и вне контекста сегодняшней задачи.
+- Один факт — одно место. Нужен в двух секциях — дай ссылку `path:line`, а не копию.
+- Подробные правила по каждой секции — `references/section-rules.md`.
+
+## 5. Дедупликация: поиск до записи
+
+1. Сформулируй 1–3 термина по теме (имя модуля, команда, текст ошибки, синонимы: «очереди/jobs/queue»).
+2. По каждому: `project_memory(action="search", project="<slug>", query="<термин>", maxChars=4000)`.
+3. Нашёл — `read` секцию и дополни существующий пункт; не создавай второй.
+4. Не нашёл — добавь новый пункт.
+5. После записи — `read` секцию: дубля нет, секрета нет, ссылка существует.
+
+Запрещено: дублировать один факт в журнале и нескольких секциях; писать почти одинаковые пункты разными словами.
+
+## 6. Лимиты размера
+
+- Каждая секция ≤ 40 KB. Приближаешься к лимиту — сокращай до выводов и ссылок.
+- 1 пункт — 1–3 строки; без воды, повторов и пересказа кода.
+- Подробности, таблицы и длинные списки — в reference-файлы проекта (`docs/`, `references/`, README); в секции — ссылка `path:line`.
+- `JOURNAL/` уже разделён по месяцам: не раздувай месяц, повторяющиеся выводы своди в секции.
+- Раздутая секция — признак того, что в досье тащат детали реализации; перенеси их в проект и оставь ссылки.
+
+## 7. Свежесть и INDEX.json
+
+`INDEX.json` — машинный файл хранилища; вручную не редактируется. Значимые поля:
+- `lastAnalyzedAt` — когда досье проанализировано целиком (а не косметически поправлено);
+- `git.branch`, `git.head` — ветка и коммит, на которых сделан анализ;
+- `confidence` — сводная уверенность: высокая при ключевых `[проверено]`, средняя при смеси, низкая при заметном `[устарело]`.
+
+Правила:
+- В начале сессии `status`; сравни `git.head`/ветку с текущими:
+  `git -C <root> rev-parse --abbrev-ref HEAD` и `git -C <root> rev-parse --short HEAD`.
+- Расходятся — досье устарело: перечитай затронутые секции, обнови факты, старые пометь `[устарело]`.
+- Полный анализ (`project-deep-dive`) — в отчёте укажи, на каком коммите он сделан; частичная правка не должна выглядеть как полный анализ.
+- `confidence` повышай только новыми `[проверено]`; понижай при `[устарело]` и большом объёме `[выведено]`.
+- Если после записи `status` показывает неактуальные поля — это расхождение инструмента: зафиксируй в отчёте и сообщи, но `INDEX.json` руками не правь.
+
+## 8. Порядок конца сессии (5 шагов)
+
+1. `status` — проект и свежесть.
+2. `search` по темам сессии (1–3 запроса).
+3. `append_journal` — запись по шаблону §3.
+4. `update_section` — только долговечные факты, одна секция — один вызов.
+5. `read` 1–2 изменённые секции и проверка по чек-листу §9; в отчёт — что записано.
+
+## 9. Финальный чек-лист
+
+- [ ] `status` вызван, проект определён.
+- [ ] `search` был до записи, дублей нет.
+- [ ] Журнал записан по шаблону, все пять пунктов на месте.
+- [ ] Секции обновлены только долговечными фактами.
+- [ ] Секретов, PII и копий кода нет.
+- [ ] У ключевых утверждений метка `[проверено]`/`[выведено]`/`[устарело]` и ссылка `path:line`.
+- [ ] Секции ≤ 40 KB; детали вынесены в references.
+- [ ] Свежесть в порядке: `git.head` соответствует анализу, устаревшее помечено.
+- [ ] Пользователю перечислено, что записано.
+
+## 10. Антипаттерны
+
+- Писать в досье после каждого шага: журнал — да, секции — нет.
+- Дублировать один факт в нескольких секциях и журнале.
+- Копировать код, логи, дампы, переписку.
+- Секреты и PII в журнале («пароль ...», «токен ...»).
+- Править файлы досье и `INDEX.json` руками.
+- Превращать `PROJECT.md` в дневник.
+- Заявлять полный анализ после косметической правки.
+- Раздувать секцию до огромного размера вместо ссылок.
+- Записывать одноразовые детали, которые не переживут сессию.
+
+## 11. Связанное
+
+- Первичный анализ проекта — `project-deep-dive`.
+- Процесс разработки — `dev-workflow`; финальное ревью — `code-review-checklist`.

package/skills/project-memory-maintenance/references/journal-template.md

@@ -0,0 +1,48 @@
+# Шаблон журнала проекта
+
+Журнал — хронология значимых сессий. Файл: `JOURNAL/YYYY-MM.md` (месяц определяется датой записи).
+Пишется действием `append_journal`, не вручную.
+
+## Точный шаблон
+
+```markdown
+## YYYY-MM-DD — <краткое название сессии>
+- Что делали: ...
+- Что выявили: ...
+- Решения: ...
+- Проверки: ...
+- Осталось: ...
+```
+
+## Требования к записи
+
+| Пункт | Что писать | Объём |
+|---|---|---|
+| Что делали | конкретные действия и затронутые области | 1–3 строки |
+| Что выявили | факты, меняющие понимание проекта: причины, зависимости, ловушки | 1–3 строки |
+| Решения | что выбрали и почему (альтернативу — одной фразой) | 1–3 строки |
+| Проверки | что запускалось и результат: тесты, линтер, сборка, ручной сценарий | 1–3 строки |
+| Осталось | следующие шаги, риски, открытые вопросы | 1–3 строки, «нет» допустимо |
+
+- Все пять пунктов обязательны; пустой пункт не удаляй, пиши «нет».
+- Ссылки на файлы — `path:line`, без копий кода и логов.
+- Секреты и PII вырезаются: «ошибка с `DB_PASSWORD` (значение не сохранено)».
+- Одна сессия — одна запись. Продолжение в тот же день — дополняй последнюю запись или пиши отдельную с пометкой «продолжение».
+
+## Пример
+
+```markdown
+## 2026-11-04 — разбор очередей и деплоя
+- Что делали: прочитали `config/queue.php`, `app/Jobs/*`, CI-пайплайн; проверили команды запуска.
+- Что выявили: воркер запускается только на проде через systemd, локально очередь работает в sync-режиме; ретраи не настроены.
+- Решения: в досье зафиксировали как ловушку; локальные тесты очередей требуют `QUEUE_CONNECTION=database`.
+- Проверки: `php artisan queue:work --once` на тестовой БД — успешно; PHPUnit — 42 теста зелёные.
+- Осталось: проверить поведение при падении воркера; уточнить таймаут ретраев у владельца.
+```
+
+## Антипримеры
+
+- «Сделали задачу» — что именно, где, чем проверено, что осталось.
+- Копия вывода тестов на 100 строк — оставь счётчик и путь к отчёту.
+- «Исправили пароль в .env на SECRET123» — секрет, так нельзя.
+- Шесть записей за один день по одному шагу — одна запись на сессию.

package/skills/project-memory-maintenance/references/section-rules.md

@@ -0,0 +1,57 @@
+# Правила обновления секций досье
+
+Общие принципы для всех секций:
+- Только долговечные факты: верны через месяц и вне сегодняшнего контекста.
+- Ссылка `path:line` вместо копии кода; одно утверждение — один источник.
+- Ключевые утверждения с меткой `[проверено]/[выведено]/[устарело]`.
+- Объём секции ≤ 40 KB; детали — в файлах проекта, в секции — ссылка.
+- Перед правкой — `read`, после правки — `read` обратно (проверка дублей и секретов).
+
+## PROJECT.md
+- Обновляй: сменился стек или версии, переехал репозиторий/прод, другой способ запуска, изменился владелец или статус.
+- Структура: назначение, стек и версии, расположение (копия/прод), запуск, статус и владелец.
+- Не пиши: историю сессий, подробности реализации, списки файлов (это `CODE-MAP`).
+- Ошибка: «сегодня настроили окружение» — это журнал, а не проект.
+
+## ARCHITECTURE.md
+- Обновляй: новый/удалённый компонент, изменение границ, потока данных, очередей/крона, внешних сервисов, ключевое решение.
+- Структура: компоненты и границы, точки входа, поток данных (текстом), внешние зависимости, решения и компромиссы.
+- Не пиши: детали алгоритмов, полный список классов, код.
+- Помечай `[выведено]`, если границы восстановлены по косвенным признакам.
+
+## CODE-MAP.md
+- Обновляй: новый модуль/маршрут/точка входа/сервис/конфиг/тест; сдвинулись якоря после рефакторинга.
+- Структура: таблица «область | путь | зачем»; точки входа; модели и схема; тесты; конфиги.
+- Не пиши: код и пересказ методов; записи без назначения.
+- Проверяй актуальность путей перед сохранением: мёртвая ссылка хуже отсутствующей.
+
+## INVARIANTS.md
+- Обновляй: появилось жёсткое правило, подтверждённое тестом, пользователем или инцидентом.
+- Структура на пункт: правило → почему → как проверить → источник `path:line`/тест.
+- Не пиши: советы, вкусовые предпочтения, «желательно».
+- Устаревший инвариант не удаляй молча: помечай `[устарело]` и указывай, чем заменён.
+
+## GOTCHAS.md
+- Обновляй: встретили неочевидную ловушку с воспроизводимым симптомом и обходом.
+- Структура: симптом → причина → обход → риск, если игнорировать.
+- Не пиши: банальности («проверяй null»), предположения без подтверждения.
+- Ловушка, исправленная навсегда (например, баг закрыт), помечается `[устарело]`.
+
+## RUNBOOK.md
+- Обновляй: изменились команды запуска/тестов/сборки, окружение, деплой, откат, бэкап, места логов.
+- Структура: окружение, установка, запуск, тесты, сборка, деплой и откат, бэкап, диагностика.
+- Не пиши: объяснение архитектуры (это `ARCHITECTURE`).
+- Команды копируй из README/AGENTS/CI; не сочиняй «примерно так».
+- Для опасных команд явно: когда нельзя запускать (прод, боевая БД).
+
+## JOURNAL/YYYY-MM.md
+- Обновляй: каждая значимая сессия (см. §3 основного файла).
+- Пиши только через `append_journal`.
+- Не пиши: дампы, длинные логи, секреты, пересказ чата.
+- Не смешивай журнал с досье: «что делали» остаётся здесь, «как устроено» — в секциях.
+
+## INDEX.json
+- Ручная правка запрещена.
+- Отражает свежесть: `lastAnalyzedAt`, `git.branch`, `git.head`, `confidence`.
+- `lastAnalyzedAt` — только после полного анализа, не после каждой правки секции.
+- Если `status` показывает расхождение с фактическим состоянием — зафиксируй в отчёте, не правь файл.

package/skills/release-and-deploy/SKILL.md

@@ -0,0 +1,39 @@
+---
+name: release-and-deploy
+description: "Универсальный выпуск и выкатка — версионирование, сборка артефакта, checksums, безопасный деплой, smoke-проверки, откат."
+whenToUse: "При подготовке релиза/обновления любого проекта и при выкатке на сервер."
+user-invocable: true
+---
+
+# Релиз и выкатка (универсально)
+
+## Принципы
+- Артефакт собирается **один раз** и выкатывается неизменным (immutable release).
+- Версия — по SemVer/правилам проекта: feature → minor, fix → patch, breaking → major; фиксируется в артефакте и на сервере.
+- Перед выкаткой — бэкап БД/файлов и известный план отката.
+- Выкатка — контролируемая: maintenance-режим на время миграций, smoke после.
+
+## Сборка
+1. Все проверки зелёные: линтер, статанализ, тесты (unit/feature), E2E/UI для интерфейса.
+2. Не включать в артефакт: `.env`, `vendor/`, `node_modules/`, сборки, `storage/`, `.git`.
+3. **Checksums** (SHA-256) артефакта; записать в `checksums.txt`.
+4. Зафиксировать состав изменений (CHANGELOG/RELEASE-NOTES): что изменилось, миграции, риски.
+
+## Выкатка
+1. Проверить целостность артефакта (`sha256sum`).
+2. Бэкап БД + файлов + текущего кода (для отката).
+3. Применить артефакт по штатной процедуре проекта.
+4. Зависимости/сборка — только как в штатном скрипте (не руками вразнобой).
+5. Миграции — аддитивные; при риске maintenance-режим.
+6. Перезапустить процессы (очереди, php-fpm, воркеры), сбросить/собрать кэши.
+7. Smoke: ключевые URL, вход, основная функция, логи без ошибок.
+
+## Откат
+- Код: предыдущий артефакт/папка/тег.
+- БД: восстановление из бэкапа — только если релиз менял данные/схему.
+- Снять maintenance, повторить smoke, сообщить пользователям.
+
+## После релиза
+- Наблюдать логи/метрики 15–30 минут; проверить фоновые задачи.
+- Записать факт выкатки и результат проверок в память проекта/CHANGELOG.
+- Старые артефакты хранить до подтверждения стабильности (потом чистить).

package/skills/requirements-and-planning/SKILL.md

@@ -0,0 +1,115 @@
+---
+name: requirements-and-planning
+description: "Анализ задачи и планирование: требования, критерии приёмки, декомпозиция, риски, варианты решений и проверяемый план — для кода, дизайна, SEO, данных, релизов и любых проектов."
+whenToUse: "Любая новая задача до реализации: понять запрос, уточнить неясное, зафиксировать критерии приёмки, спланировать шаги и проверки; анализ/исследование/сравнение вариантов."
+user-invocable: true
+---
+
+# REQUIREMENTS & PLANNING — сначала думать, потом делать
+
+> Цель: не «начать кодить и по ходу разобраться», а **понять задачу, договориться о результате и
+> спланировать проверяемые шаги**. Это снижает переделки, риски и потерю данных — и повышает качество.
+
+## 0. Контракт
+1. **Одно предложение:** переформулируй запрос своими словами — что должно измениться для пользователя.
+2. **Неясное — уточняй** (одним сообщением, 1–3 вопроса), но не блокируйся: если вопрос не критичен,
+   зафиксируй допущение и двигайся; критичное (данные, деньги, права, необратимость) — только после ответа.
+3. **Критерии приёмки — до кода.** «Готово» должно быть проверяемым (Given/When/Then или чек-лист).
+4. **План — до правок:** шаги, затронутые файлы/системы, зависимости, проверки, откат.
+5. **Scope guard:** явно перечисли, что входит и что НЕ входит; не расширяй молча.
+6. **Финал:** отчёт «что сделано / как проверено / риски / что дальше» — по факту критериев.
+
+## 1. Процесс (8 шагов)
+
+### Шаг 1. Понять запрос
+- Кто пользователь и в каком контексте? Что болит? Какая цель (сэкономить время, снизить ошибки, продать, найти)?
+- Что уже есть (текущее поведение/скриншот/код)? Что должно стать?
+- Формат результата: экран? файл? архив? релиз? отчёт? API?
+
+### Шаг 2. Контекст и разведка
+- Прочитай память/досье проекта (`memory/INDEX.md`, `memory/projects/<проект>.md`), `AGENTS.md`.
+- Найди затронутые файлы, маршруты, модели, шаблоны, тесты, конфиги.
+- Проверь ограничения: стек, версии, окружение, права, бэкапы, кэш, SEO, дизайн-система.
+- Не проектируй вслепую: 10 минут разведки экономят часы.
+
+### Шаг 3. Требования и критерии приёмки
+Заполни:
+- **Цель:** <одно предложение>
+- **Пользователь и сценарий:** <кто/что делает/зачем>
+- **Входит:** <...>
+- **Не входит:** <...>
+- **Критерии приёмки:** проверяемые пункты (например: «заявка создаётся с выбранной срочностью», «на 390px нет overflow», «title/description/canonical на странице», «PHPUnit зелёный, +2 теста»).
+- **Ограничения:** <бюджет времени, стек, нельзя ломать…>
+
+### Шаг 4. Варианты решения
+- 2–3 варианта (если выбор неочевиден): плюсы, минусы, риски, трудозатраты.
+- Выбери и обоснуй. Для рискованных — предпочти самый обратимый.
+- Для крупных задач — вертикальный срез (тонкая сквозная реализация), а не «сначала весь бэкенд».
+
+### Шаг 5. План
+```
+1. <шаг> — файлы: ... — проверка: ...
+2. <шаг> — файлы: ... — проверка: ...
+...
+```
+- Декомпозируй до 1–2 часовых шагов; отметь зависимости и параллелизм.
+- Для каждого шага — как проверить (тест/скриншот/запрос/аудит).
+- Зафиксируй порядок: сначала бэкап/подготовка, потом изменения, потом проверка, потом откат-план.
+
+### Шаг 6. Риски и откат
+- Таблица: риск → вероятность/влияние → митигация.
+- Что может сломаться (данные, прод, кэш, SEO, дизайн, интеграции)? Как откатим?
+- Перед необратимым: бэкап, dry-run, копия, feature-флаг.
+
+### Шаг 7. Исполнение с чекпоинтами
+- Двигайся по плану; после каждого блока — быстрая проверка (тест/линт/скриншот).
+- Отклонение от плана — фиксируй и объясняй; scope creep — в отдельный список «потом».
+- Для UI/SEO/БД используй соответствующие скиллы и их гейты.
+
+### Шаг 8. Сдача
+- Сверь результат с критериями приёмки (таблица «критерий → как проверено → результат»).
+- Отчёт: что сделано, как проверено, риски/ограничения, что дальше.
+- Обнови память (`SESSIONS.md`, досье) и версию/документацию, если применимо.
+
+## 2. Шаблон брифа (короткий)
+```
+Задача: <одно предложение>
+Зачем: <польза>
+Пользователь/сценарий: <...>
+Входит / Не входит: <...>
+Критерии приёмки: <3–7 проверяемых пунктов>
+Ограничения: <стек, сроки, нельзя ломать>
+Риски/откат: <...>
+План: <3–7 шагов с проверками>
+```
+
+## 3. Шаблон критериев приёмки
+- Given <контекст>, when <действие>, then <результат>.
+- UI: 1440/768/390, light/dark, состояния, контраст AA, нет overflow.
+- SEO: title/description, один H1, canonical, OG, schema, sitemap/robots (если применимо).
+- API/данные: код ответа, валидация, транзакция, права, отсутствие N+1.
+- Тесты: baseline не ухудшен, новые тесты зелёные.
+- Релиз: артефакт собран, checksum, инструкция, откат.
+
+## 4. Эвристики оценки
+- Небольшая правка — 0,5–2 ч; компонент — 2–6 ч; экран — 0,5–2 дня; фича с БД/тестами — 1–3 дня.
+- Неизвестный стек/чужая кодовая база — ×1,5–2 к оценке.
+- Всегда добавляй время на проверку (тесты/скриншоты/аудит) и на непредвиденное (+20–30%).
+- Если оценка > 2 дней — дели на этапы с отдельной сдачей.
+
+## 5. Антипаттерны
+- Начать с кода, не поняв, что считать «готово».
+- Уточнять «потом», когда уже всё сломано.
+- План из одного пункта «сделать всё».
+- Нет критериев приёмки → бесконечные правки и споры.
+- Нет откат-плана для миграций/релизов/прод-правок.
+- Молча расширить scope («заодно переделал ещё 10 страниц»).
+- Считать «сделал» = «написал код» (без проверки и отчёта).
+
+## 6. Чек-лист перед стартом
+- [ ] Запрос переформулирован одним предложением.
+- [ ] Критичные неясности уточнены или зафиксированы допущения.
+- [ ] Прочитана память/досье, найдены затронутые файлы.
+- [ ] Критерии приёмки зафиксированы.
+- [ ] Есть план с проверками и откатом.
+- [ ] Подобраны скиллы (`skills-router`) под типы работ.

package/skills/security-review/SKILL.md

@@ -0,0 +1,36 @@
+---
+name: security-review
+description: "Универсальный чек-лист безопасности — аутентификация, авторизация, ввод/вывод, загрузки, секреты, зависимости."
+whenToUse: "При добавлении маршрутов, форм, API, загрузок, прав доступа; перед релизом и ревью."
+user-invocable: true
+---
+
+# Безопасность (универсальный чек-лист)
+
+## Доступ
+- [ ] Каждый маршрут явно защищён (auth + нужное право/роль); публичными остаются только осознанные.
+- [ ] Нет IDOR: доступ к объекту проверяет владельца/право, а не только «авторизован».
+- [ ] Привилегированные действия (назначить роль, удалить, изменить чужие данные) — отдельное право.
+- [ ] Сессия: регенерация при входе, корректный выход, разумный срок жизни, cookie HttpOnly/Secure.
+
+## Ввод
+- [ ] Валидация на сервере для всех полей (тип, длина, диапазон, формат); клиентская — только UX.
+- [ ] Нет SQL-конкатенации пользовательских данных; только параметры/query builder/ORM.
+- [ ] Массовое присвоение ограничено (`fillable`/явные поля).
+- [ ] Загрузки: whitelist расширений и MIME, лимит размера, хранение вне webroot (или безопасная отдача), уникальные имена.
+- [ ] Нет SSRF/XXE/десериализации недоверенных данных; внешние URL — валидировать.
+
+## Вывод
+- [ ] Экранирование по контексту; «безопасный HTML» — только через санитайзер с whitelist.
+- [ ] Никаких `{!! !!}`/`innerHTML` для пользовательских данных.
+- [ ] Заголовки безопасности: CSP, X-Content-Type-Options, правильный Content-Disposition для файлов.
+- [ ] Персональные данные не попадают в логи/URL/скриншоты.
+
+## Секреты и зависимости
+- [ ] Секреты только в `.env`/секрет-хранилище; `.env` в `.gitignore`; ротация при утечке.
+- [ ] Нет дебаг-флагов в продакшене (`APP_DEBUG=false`), подробные ошибки не отдаются наружу.
+- [ ] Зависимости: аудит (`composer audit`, `npm audit`), обновление критичных.
+- [ ] Ограничение частоты на вход/чувствительные действия; защита от перебора.
+
+## Реакция на инцидент
+- Зафиксировать, изолировать, сменить секреты, выпустить фикс, уведомить по политике; записать в память.

package/skills/seo/README.md

@@ -0,0 +1,60 @@
+# SEO-скилл (`seo`) — установка и карта
+
+Полноценный скилл «SEO-эксперт» для агента: техническое SEO, on-page, структурированные данные, E-E-A-T/YMYL
+(медицина), контент, стек-рецепты (Laravel/Blade, Bitrix/Aspro, React/Vite, статика), аудит и измерение.
+Правило скилла: **любой веб-артефакт (страница, шаблон, мета, URL, контент) пишется с SEO по умолчанию**.
+
+Актуальность: **04.11.2026** (Google Search Central + Яндекс Вебмастер + schema.org + web.dev).
+Спорные/меняющиеся места в текстах помечены «проверить на актуальной версии».
+
+## Установка
+
+1. Скопировать каталог в скиллы DSH:
+   `projects/seo-skill/` → `%USERPROFILE%\.dsh\skills\seo\`
+   (SKILL.md в корне, `references/`, `assets/` — рядом).
+2. Проверить каталог скиллов: скилл должен появиться как `seo` (frontmatter: `name: seo`,
+   `whenToUse`, `user-invocable: true`).
+3. Агент загружает его через tool `skill` перед любой веб-задачей; глобальный контракт в `~/.dsh/AGENTS.md`
+   §1b требует загружать `seo` для любого веб-артефакта.
+4. Инструмент `assets/scripts/seo-audit.mjs` добавляет qa-toolsmith (task-5) — контракт интерфейса уже
+   зафиксирован в `assets/scripts/README.md`.
+
+## Что внутри
+
+| Файл | Назначение |
+|---|---|
+| `SKILL.md` | контракт «SEO по умолчанию», процесс 8 шагов, матрица по типам страниц, SEO-GATE, антипаттерны, шаблоны title/description, Google vs Яндекс, lite-режим |
+| `references/technical-seo.md` | краулинг/индексация, статусы, robots.txt, sitemap, canonical, дубли, пагинация, фасеты, hreflang, CWV, JS/SPA, лог-анализ, миграции URL, топ-20 ошибок |
+| `references/on-page.md` | title/description/H1–H6, URL, структура страницы услуги, изображения, анкоры, OG/Twitter, крошки, сниппет, примеры «плохо→хорошо» |
+| `references/structured-data.md` | JSON-LD: граф сайта, BreadcrumbList, MedicalWebPage, Physician, MedicalClinic, Service/MedicalProcedure, FAQPage, Article, Event, Product + что устарело в 2026 + валидация |
+| `references/eeat-medical.md` | YMYL: авторство врачей, рецензент, даты, источники, дисклеймеры, лицензия, локальная клиника (NAP, Яндекс Бизнес, 2ГИС, GBP), 152-ФЗ/38-ФЗ, чек-лист YMYL-гейта |
+| `references/stack-recipes.md` | Laravel/Blade (SeoData, meta-компонент, sitemap/robots-роуты, 301, кэш), Bitrix/Aspro (SEO-шаблоны инфоблоков, canonical, 404, редиректы, robots/sitemap, кэш), React/Vite (Astro/Next/SPA), статика, nginx/.htaccess, проверки |
+| `references/content-seo.md` | SEO-бриф, интенты, семантика/кластеры (Вордстат, Москва), структура лендинга и статьи, перелинковка, CTA, freshness, локализация, ИИ-ответы, редакционный процесс |
+| `references/audit-checklist.md` | 107 проверок P0/P1/P2 по 12 областям + **автоматизируемые проверки (seo-audit.mjs)** + шаблоны отчёта + приоритизация |
+| `references/measurement.md` | GSC, Яндекс Вебмастер, GA4/Метрика, KPI, «до/после», UTM, мониторинг/алерты, шаблоны отчётов |
+| `assets/snippets/` | `meta.blade.php`, JSON-LD (организация, клиника, врач, MedicalWebPage, FAQ, крошки), `robots.txt`, `sitemap.xml` + urlset |
+| `assets/README.md` | как пользоваться сниппетами, статусы разметки в 2026, особенности Битрикса |
+| `assets/scripts/README.md` | контракт `seo-audit.mjs`: интерфейс, выходные файлы, схема JSON, список проверок |
+
+## Ключевые правила (краткая версия)
+
+1. Каждая страница: `title`, `description`, `canonical`, `robots`, OG, **один H1**, семантика, JSON-LD, `alt`,
+   внутренние ссылки, читаемый URL — иначе страница не готова.
+2. Интент важнее ключевых слов; один интент = один URL, без каннибализации.
+3. Медицина = YMYL: автор-врач, рецензент, даты, источники, дисклеймер, без обещаний излечения.
+4. SEO-данные — в **исходном HTML** (SSR/SSG), а не после JS.
+5. Любая смена URL — только с 301 + обновлением sitemap и внутренних ссылок.
+6. **Google + Яндекс сразу**: ИКС, регион, Clean-param, Яндекс Бизнес; не оптимизируй под одного.
+7. Проверяемо: Rich Results Test / Schema validator / GSC / Вебмастер / PSI — а не «я добавил meta».
+8. 2026: FAQ rich results отключены (07.05.2026), HowTo удалён, llms.txt Google не использует,
+   AI Overviews/AI Mode учитываются в общем трафике GSC.
+
+## Проверка комплектности
+
+- [x] SKILL.md с frontmatter (`name`, `description`, `whenToUse`, `user-invocable`), 8 шагов, гейт, антипаттерны.
+- [x] 8 файлов в `references/` (technical, on-page, structured-data, eeat-medical, stack-recipes, content-seo,
+      audit-checklist, measurement).
+- [x] 107 проверок с P0/P1/P2 + порог сдачи + шаблон отчёта.
+- [x] Готовые сниппеты и README для assets.
+- [x] Русский рынок (Google + Яндекс) и медицинский YMYL учтены в каждом релевантном файле.
+- [x] Ссылки на первоисточники; спорные данные помечены «проверить».