From 413e563a610958024ce0a46e7777ac92441a99f7 Mon Sep 17 00:00:00 2001 From: Fedorov Vladimir Date: Wed, 2 Sep 2026 00:21:08 +0700 Subject: [PATCH] updates --- .dsh/skills/task-execution/SKILL.md | 154 ---------------------------- .dsh/task-plan.md | 49 --------- .gitignore | 3 + src/components/GamePage.vue | 21 ++-- 4 files changed, 9 insertions(+), 218 deletions(-) delete mode 100644 .dsh/skills/task-execution/SKILL.md delete mode 100644 .dsh/task-plan.md diff --git a/.dsh/skills/task-execution/SKILL.md b/.dsh/skills/task-execution/SKILL.md deleted file mode 100644 index 99d58bb..0000000 --- a/.dsh/skills/task-execution/SKILL.md +++ /dev/null @@ -1,154 +0,0 @@ ---- -name: task-execution -description: Выполняет любую нетривиальную задачу по процессу «план → ревью сеньёром → правки → выполнение → ревью результата → правки» в проекте «Вечерний детектив» (Vue 3.5 + Vite + Pinia + Naive UI). План и результат проверяет субагент в роли senior developer; цикл повторяется, пока не устранены блокирующие замечания. Ниты и уточнения формулировок не блокируют одобрение — фиксируются и могут остаться неисправленными. При неясностях агент задаёт вопросы пользователю. Загружай для реализации фичи, исправления бага, рефакторинга, написания кода или документации, когда задача не сводится к одному тривиальному действию. -whenToUse: Пользователь просит выполнить задачу в проекте «Вечерний детектив» (написать код, починить баг, отрефакторить, задокументировать, что-то исследовать и внедрить) и задача не является тривиальным одношаговым действием. Для тривиальных правок скил можно не применять. ---- - -# Выполнение любой задачи: план → сеньёр → правки → выполнение → сеньёр → правки - -## Контекст - -Адаптация скила `task-execution` под проект «Вечерний детектив» (фронтенд). Любая нетривиальная задача выполняется строго по циклу: сначала **план**, затем **ревью плана сеньёром** с правками до одобрения, затем **выполнение** по одобренному плану, затем **ревью результата сеньёром** с правками, пока не устранены блокирующие замечания. Замечания делятся на **блокирующие** (исправляются обязательно) и **ниты** (фиксируются, но не блокируют одобрение и могут остаться неисправленными). На каждом этапе, если что-то неясно, задаются вопросы пользователю. - -Проектные конвенции — в `AGENTS.md` репозитория (структура `src/`, стиль кода и импортов, дизайн-канон «бумажного детектива», палитра, правила по API-клиентам и сгенерированному коду). Сеньёр и исполнитель сверяются с ним на каждом цикле. - -## Классификация замечаний - -- **Блокирующее ([BLOCKER])** — влияет на функциональность, корректность, безопасность, целостность данных, совместимость, достижимость шага плана, ломает сборку/тесты, нарушает конвенции проекта (структура, импорты, палитра и стилистика из `AGENTS.md`), создаёт регрессию. Такие замечания исправляются все, без исключения. -- **Нит ([NIT])** — уточнение формулировки, стиль, типографика, «на будущее», рекомендация без реального риска, альтернатива, которая не меняет поведение. Ниты фиксируются (в файле состояния или `todo/`), но НЕ обязательны к исправлению и не блокируют `APPROVED`. -- Метку ставит сеньёр в каждом замечании. Если метка отсутствует или неоднозначна — трактуй замечание как блокирующее (осторожность в пользу качества); при сомнении можно спросить пользователя. - -## Роли - -- **Исполнитель** — ты (агент). Составляешь план, выполняешь, правишь по блокирующим замечаниям, фиксируешь ниты. -- **Сеньёр (senior developer)** — отдельный субагент, запускаемый через `subagent` **один раз на задачу** и переиспользуемый между раундами через `send_message` (он помнит свои предыдущие замечания и дельты — не противоречит себе и не перечитывает весь файл состояния каждый раунд). Он **не видит наш диалог**, поэтому каждый промпт ревью должен быть самодостаточным — но самодостаточность достигается за счёт внешнего файла состояния, а не дублирования всего плана в промпте (см. правило 9). Новый сеньёр создаётся только при смене задачи или переполнении контекста субагента (тогда — со сводкой уже принятых решений). -- **Пользователь** — источник требований и финальный судья. Ему задаются вопросы при неясностях. - -## Обязательные правила - -1. **Сначала план — потом выполнение.** Не начинай выполнение, пока сеньёр не одобрил план (ответил `APPROVED`). -2. **Ревью плана и результата — только через субагента в роли senior developer** (см. шаблоны промптов ниже). **Создай сеньёра один раз** (первый раунд — `subagent` с `run_in_background: true`), далее каждый раунд — `send_message` тому же субагенту с дельтой. Ответ субагента приходит уведомлением (не синхронно): пока он работает, продолжай независимые шаги, по уведомлению забирай результат. -3. **Блокирующие замечания исправляются все, без выбора.** Нельзя отбрасывать `[BLOCKER]` «потому что не согласен»: если не согласен — верни уточняющий вопрос сеньёру или спроси пользователя. **Ниты (`[NIT]`) исправлять не обязательно**: зафиксируй их в файле состояния или `todo/` и продолжай. -4. **Цикл повторяется, пока сеньёр не вернёт `APPROVED`** — и для плана, и для результата. `APPROVED` достижим при наличии только нитов (сеньёр может вернуть `APPROVED (ниты: ...)`); блокирует цикл только наличие `[BLOCKER]`. -5. **Неясно — спроси.** На любом этапе (задача, шаг плана, замечание сеньёра) при неоднозначности задай вопрос пользователю через `ask_user_question`. Догадки вместо вопросов — ошибка. -6. **Отслеживай прогресс** через `todo_write`: план из шага 2 переносится в todo-список, пункты отмечаются по мере выполнения. -7. **Профильные скилы** (например `frontend-dev` — база знаний фронтенд-разработчика) — источник правил «как делать» для конкретной задачи. Этот скил управляет процессом «как вести задачу»; оба применяются вместе. -8. **Бюджет раундов ревью — 3 на цикл** (план и результат отдельно). В шаблонах промптов требуй от сеньёра перечислить **все замечания одним списком за один заход** с метками `[BLOCKER]`/`[NIT]`. После 3 раундов с неисправленными `[BLOCKER]` остановись и спроси пользователя: продолжать цикл или зафиксировать оставшиеся блокеры как известные ограничения (не растягивай полировку на десятки раундов). -9. **Дифф-ревью и внешнее состояние.** План, чек-лист и учёт замечаний держи во внешнем файле состояния (например, `.dsh/task-plan.md`). Промпт ревью содержит: задачу, путь к файлу состояния, **короткую дельту** «что изменилось с прошлого раза» и `git diff` изменённых файлов. Не пересказывай ревьюеру весь план и всю историю замечаний — файл состояния он прочитает сам (это его контекст, а не наш). -10. **Саморевью до отправки.** Перед первым и каждым повторным ревью прогоняй фактические проверки, которые сеньёр всё равно сделает: поведение функций на реальных данных (например, `res.error` у API-клиентов, `computed`-значения, типизацию `defineProps` с `PropType`), чтение сгенерированного кода (`src/api/generated/**`), соответствие палитре и стилистике из `AGENTS.md`, арифметику лимитов. «Ревью результата» отправляй как `git diff` + выводы проверок, а не как пересказ плана. - -## Шаги - -### 1. Уточни задачу - -Разберись, что именно нужно сделать. Если неясны цель, объём, ограничения или критерии приёмки — задай вопросы пользователю до составления плана. - -### 2. Составь план - -План должен содержать: - -- **Цель** и ожидаемый результат; -- **Шаги** с конкретными файлами, командами и артефактами; -- **Проверки** — обязательный минимум проекта: `npm run type-check` → `npm run lint` → `npm run lint:css`; при затрагивании сборки/конфигов — `npm run build`. Для проверки в браузере — dev-сервер (`npm run dev`) в фоне; -- **Критерии готовности** — что считается «сделано» (в т.ч. чек-лист раздела 5 `AGENTS.md`); -- **Риски и открытые вопросы** (если есть). - -Заведи todo-список через `todo_write` в соответствии с планом. - -### 3. Ревью плана сеньёром - -Сохрани план и критерии в файл состояния (например, `.dsh/task-plan.md`), прогони саморевью (правило 10), затем **создай сеньёра** (`subagent`, первый раунд) с промптом по шаблону **«Ревью плана»** (ниже). Ответ сеньёра приходит уведомлением (правило 2) — по уведомлению забирай результат: либо `APPROVED`, либо список замечаний с метками. - -### 4. Цикл правок плана - -- Есть блокирующие замечания → исправь их в файле состояния (и todo-список), отправь на ревью **повторно ТОМУ ЖЕ сеньёру** через `send_message`: в промпт добавь только дельту «что изменилось с прошлого раза» (правило 9). -- Ниты → зафиксируй в файле состояния (раздел «Ниты / известные ограничения») или `todo/`, не обязательно исправляй. -- Повторяй, пока не получишь `APPROVED`; после 3 раундов с неисправленными `[BLOCKER]` — спроси пользователя (см. «Ограничение итераций»). - -### 5. Выполнение - -Выполняй строго по одобренному плану, отмечая прогресс в `todo_write`. Соблюдай конвенции проекта из `AGENTS.md` (структура `src/`, импорты, палитра и стилистика, API только через сгенерированные клиенты, UI-контролы — только naive-ui). Если в ходе выполнения стало ясно, что план нужно изменить — не отклоняйся молча: вернись к шагу 3 с обновлённым планом. - -### 6. Ревью результата - -Сначала сам проверь результат (прогони проверки из плана: `npm run type-check` → `npm run lint` → `npm run lint:css` → при необходимости `npm run build`, правило 10), затем отдай его сеньёру по шаблону **«Ревью результата»** через `send_message` (тот же субагент): `git diff` изменённых файлов + выводы проверок. Сеньёр сверяет результат с планом (файл состояния) и критериями, проверяет корректность и соблюдение конвенций проекта (включая дизайн-канон из `AGENTS.md`). - -### 7. Цикл правок результата - -Исправляй блокирующие замечания, повторяй ревью **тому же сеньёру** через `send_message`, пока не вернёт `APPROVED`. Ниты — фиксируй в `todo/` или файле состояния, не обязательно исправляй. При каждом повторе сообщай сеньёру только дельту — что изменилось с прошлого раза (правило 9). После 3 раундов с неисправленными `[BLOCKER]` — спроси пользователя. - -### 8. Финальный отчёт - -Кратко сообщи пользователю: что сделано, какие файлы затронуты, как проверялось (какие из `npm run type-check` / `npm run lint` / `npm run lint:css` / `npm run build` прошли), что план и результат одобрены сеньёром. - -## Шаблон: промпт «Ревью плана» - -План и критерии — в файле состояния (путь ниже); в промпт включай только задачу, путь к файлу, дельту с прошлого раза (если есть) и diff, если правился код. - -``` -Ты — senior developer. Оцени план выполнения задачи. - -Задача: <текст задачи> -План и критерии готовности: <путь к файлу состояния, например .dsh/task-plan.md> (прочитай сам) -Изменения с прошлого раза: <дельту или «первое ревью»> - -Проверь: полноту (нет ли пропущенных шагов), достижимость, корректность -подхода, риски, соответствие конвенциям проекта (AGENTS.md: структура src/, -импорты, палитра и стилистика, API-клиенты), наличие обязательных проверок -(npm run type-check / lint / lint:css / build), отсутствие лишних шагов. - -Классифицируй каждое замечание: -- [BLOCKER] — влияет на функциональность, корректность, безопасность, - целостность данных, достижимость шага, ломает сборку/тесты, нарушает - конвенции проекта, создаёт регрессию. Такие обязательны к исправлению. -- [NIT] — уточнение формулировки, стиль, типографика, «на будущее», - рекомендация без реального риска. Ниты не блокируют APPROVED. - -Перечисли ВСЕ замечания одним списком за один заход — включая мелочи и -ниты; не растягивай на несколько раундов. -Ответь СТРОГО одним из двух вариантов: -- APPROVED (можно с пометкой «ниты: ...») — если блокирующих замечаний нет; -- список замечаний, каждое в формате «[BLOCKER]|[NIT] <что не так> → <как исправить>». -``` - -## Шаблон: промпт «Ревью результата» - -``` -Ты — senior developer. Оцени результат выполнения задачи. - -Задача: <текст задачи> -План и критерии готовности: <путь к файлу состояния> (прочитай сам) -Результат: git diff изменённых файлов + выводы проверок (npm run type-check / -npm run lint / npm run lint:css / npm run build, при необходимости — dev-сервер) -Изменения с прошлого раза: <дельту или «первое ревью»> - -Проверь: результат соответствует плану и критериям готовности, код/текст -корректен, соблюдены конвенции проекта (AGENTS.md: структура, импорты, -палитра и стилистика «бумажного детектива», API только через сгенерированные -клиенты), нет регрессий. - -Классифицируй каждое замечание: -- [BLOCKER] — влияет на функциональность, корректность, безопасность, - целостность данных, ломает сборку/тесты, нарушает конвенции, регрессия. - Такие обязательны к исправлению. -- [NIT] — уточнение формулировки, стиль, типографика, «на будущее», - рекомендация без реального риска. Ниты не блокируют APPROVED. - -Перечисли ВСЕ замечания одним списком за один заход — включая мелочи и ниты. -Ответь СТРОГО одним из двух вариантов: -- APPROVED (можно с пометкой «ниты: ...») — если блокирующих замечаний нет; -- список замечаний, каждое в формате «[BLOCKER]|[NIT] <что не так> → <как исправить>». -``` - -## Ограничение итераций - -Если в одном цикле (план или результат) после **3 раундов** остаются неисправленные `[BLOCKER]` — остановись и спроси пользователя: продолжать цикл или зафиксировать оставшиеся блокеры как известные ограничения. Ниты не считаются причиной продолжения цикла: при одних нитах сеньёр возвращает `APPROVED (ниты: ...)`, а исполнитель фиксирует их в файле состояния или `todo/`. - -## Критерии готовности - -- [ ] План составлен и одобрен сеньёром (`APPROVED`) до начала выполнения. -- [ ] Все блокирующие замечания сеньёра по плану устранены; ниты зафиксированы (в плане/`todo/`) и не блокируют одобрение. -- [ ] Результат соответствует плану и критериям готовности, соблюдены конвенции `AGENTS.md`. -- [ ] Все блокирующие замечания сеньёра по результату устранены, получен `APPROVED`; ниты зафиксированы. -- [ ] Пройдены проверки проекта: `npm run type-check`, `npm run lint`, `npm run lint:css` (и `npm run build` при затрагивании сборки); сгенерированный код (`src/api/generated/**`) не тронут; `git commit`/`git push` не выполнялись. -- [ ] Пользователю дан финальный отчёт. diff --git a/.dsh/task-plan.md b/.dsh/task-plan.md deleted file mode 100644 index e993212..0000000 --- a/.dsh/task-plan.md +++ /dev/null @@ -1,49 +0,0 @@ -# Задача: адаптация скила task-execution под проект «Вечерний детектив» - -## Задача (от пользователя) - -> Возьми скил и сделай такой же, но для этого сервиса. -> (приложен исходный текст скила `task-execution`) - -Смысл: создать для этого репозитория (фронтенд «Вечернего детектива») скил с тем же -процессом «план → ревью сеньёром → правки → выполнение → ревью результата → правки», -но адаптированный под конвенции проекта. - -## Ожидаемый результат - -- Файл скила по адресу `.dsh/skills/task-execution/SKILL.md` (директория-бандл — - формат, который загружает harness из `/.dsh/skills//SKILL.md`). -- Имя `task-execution` (валидно по `SKILL_NAME = /^[a-z0-9]+(?:-[a-z0-9]+)*$/`). -- Frontmatter: `name`, `description`, `whenToUse`. -- Процесс и правила исходного скила сохранены полностью; адаптировано: - - проверки проекта: `npm run type-check` → `npm run lint` → `npm run lint:css` → `npm run build`; - - ссылки на конвенции `AGENTS.md` (структура `src/`, импорты, палитра и стилистика «бумажного детектива», API-клиенты, сгенерированный код); - - примеры саморевью под стек проекта (Vue/TS, `res.error`, `src/api/generated/**` вместо Go-примеров); - - профильный скил `frontend-dev` вместо `create-go-module`. - -## Критерии готовности - -- [ ] Harness обнаруживает скил (появился в каталоге доступных скилов сессии). -- [ ] Frontmatter парсится как YAML; `name`, `description`, `whenToUse` на месте; имя валидно. -- [ ] Структура и все правила исходного скила сохранены (процесс, роли, классификация, шаблоны, лимит итераций, критерии готовности). -- [ ] Адаптация под проект выполнена корректно (команды, конвенции AGENTS.md, примеры). -- [ ] Сеньёр одобрил результат (`APPROVED`); блокеры устранены, ниты зафиксированы. - -## Проверки (саморевью, правило 10) - -- Frontmatter распарсен через `yaml.parse` → keys: name, description, whenToUse. OK. -- `name: task-execution` соответствует `SKILL_NAME`. OK. -- Тело непустое, начинается с `#`. OK. -- Harness загрузил скил в каталог сессии (доступен как `task-execution`). OK. -- Сгенерированный код не тронут; `git commit`/`push` не выполнялись. OK. - -## Ниты / известные ограничения - -Ревью сеньёром (субагент 22faeca3): **APPROVED (4 нита)**, блокирующих замечаний нет. - -1. Шаг 3 «…и дождись его ответа» противоречит правилу 2 (асинхронное уведомление) — **исправлено**: «Ответ сеньёра приходит уведомлением (правило 2) — по уведомлению забирай результат». -2. Заголовок тела опускал стадии «правки» — **исправлено**: «план → сеньёр → правки → выполнение → сеньёр → правки». -3. Description длиной 623 символа обрезается в каталоге — **исправлено**: сокращено, разбито на предложения. -4. В критериях готовности не упомянут запрет `git commit`/`git push` — **исправлено**: добавлено в последний пункт критериев. - -Оговорка сеньёра: оригинал скила был приложением к запросу и ему недоступен — полнота проверена по task-plan.md и внутренней согласованности, не побайтовым диффом с оригиналом. Оригинал сверен мной при адаптации: процесс, роли, классификация, правила 1–10, шаги 1–8, оба шаблона, лимит итераций, критерии — перенесены без потерь. diff --git a/.gitignore b/.gitignore index db1f9de..02e2c88 100644 --- a/.gitignore +++ b/.gitignore @@ -30,3 +30,6 @@ coverage *.tsbuildinfo .env + +# Agent local state (skills, task plans) +.dsh/ diff --git a/src/components/GamePage.vue b/src/components/GamePage.vue index 31c879d..1466aa9 100644 --- a/src/components/GamePage.vue +++ b/src/components/GamePage.vue @@ -394,21 +394,21 @@ useSimplePolling(() => { -
- + + QR - + Ответы команд - + Настройки + @click="showDeleteGameModal = true"> Удалить игру @@ -439,7 +439,7 @@ useSimplePolling(() => { -
+ @@ -690,19 +690,10 @@ useSimplePolling(() => { font-size: 20px; } -.settings-block {} - -.settings-button { - float: right; - margin-left: 10px; -} - .settings-icon { width: 20px; } -.title-block {} - .link-button { margin-top: 20px; width: 100%;