@goodandready/dsh-kanban 0.2.2 → 0.2.8

package/docs/plans/2026-08-26-dsh-kanban-0.1.md

@@ -1,169 +0,0 @@
-# dsh-kanban — план реализации
-
-> **Для исполнителя:** это план для агента, у которого нет контекста обсуждения.
-> Перед любой правкой плагина DSH загрузи `dsh-plugin-authoring`.
-> Перед правкой профиля `web` — `dsh-web-profile-repair`.
-> Работа ведётся по `gitea-project-workflow`: issue → worktree от свежего
-> `origin/main` → WIP PR → ревью → merge → deploy → cleanup → закрытие issue.
-
-**Цель:** доска задач внутри DeepSeek Harness, которая берёт задачи из Gitea,
-показывает по ним ход работы и умеет запускать по каждой задаче отдельную
-сессию агента с выбранной моделью.
-
-**Архитектура:** отдельный плагин `@goodandready/dsh-kanban` со своим
-хранилищем задач. Gitea-доступ не дублируется — используется существующий
-плагин `@goodandready/dsh-gitea`, которому для этого добавляется сервис cordis.
-Запуск работы идёт через штатные сервисы ядра `agents`/`sessions`; плагин
-поднимает сессию и отдаёт первое сообщение, дальше работу ведёт агент по
-действующему воркфлоу.
-
-**Стек:** Node (ESM), cordis, `@deepseek-ai/schemastery`, React в браузерной
-половине через `window.__ModuleLoader__`, хранилище — `node:sqlite`.
-
-## Глобальные ограничения
-
-- Имя пакета `@goodandready/dsh-kanban` обязано совпадать в трёх местах:
-  `package.json` → `name`, `cordis.patch.yml` → `name:`, `lib/client.js` →
-  `load({ id })`. Короткий id патча — `dsh-kanban`.
-- Пространство настроек: `dsh-kanban`. Ключ слота карточки настроек обязан быть
-  равен пространству настроек, иначе карточка молча не появится.
-- Настройки — карточкой в `settings.plugin.item`. Свой раздел настроек НЕ
-  заводить. Раздел верхнего уровня заводится только для экрана доски.
-- Токен Gitea плагин не хранит, не спрашивает и не логирует. Доступ — только
-  через сервис `gitea` из `dsh-gitea`.
-- Ни абсолютных путей, ни адресов инстансов, ни имён машин в коде и README.
-  Машинно-зависимое живёт в настройках с пустым значением по умолчанию.
-- Все Git-операции — только через wrapper `git-<agent>`. Bare `git` запрещён.
-- Conventional Commits обязательны: `<type>(<scope>)!: <действие>`, footer
-  `Refs: #<номер>`.
-- Тесты идут без харнесса и без сети: `node --test test/*.test.mjs`.
-- Всё поднятое в `ctx.effect` гасится возвращённым уборщиком.
-- Хуки React объявляются выше всех возвратов.
-
-## Колонки доски
-
-Колонки повторяют реальный воркфлоу, а не абстрактный «в работе → готово».
-
-| Колонка | Признак входа |
-|---|---|
-| `backlog` | issue есть, никто не взял |
-| `in-progress` | сессия поднята, в issue есть стартовый комментарий с планом и веткой |
-| `review` | PR снят с WIP, ревьюер даёт PASS/FAIL |
-| `deploy` | PR влит в `main`, ждём согласованный deploy и production-проверку |
-| `cleanup` | ветка в Gitea, worktree и локальная ветка ещё не удалены |
-| `done` | issue закрыт И cleanup записан в итоговом комментарии |
-
-Колонка `cleanup` существует потому, что по воркфлоу задача не завершена, пока
-cleanup не сделан и не записан. Доска, отправляющая карточку в `done` по merge,
-будет врать ровно там, где копятся забытые ветки.
-
-WIP PR НЕ двигает карточку в `review`: он открывается рано и означает «работа
-идёт», а не «смотрите».
-
-## Что плагин НЕ делает
-
-Эти границы заданы воркфлоу и нарушать их нельзя:
-
-- Не создаёт ветки и worktree. По воркфлоу агент сначала делает preflight
-  (открытые ветки, `git status --short`) и только потом заводит worktree от
-  свежего `origin/main`. Плагин, создающий ветку заранее, ломает preflight.
-- Не пишет стартовый комментарий в issue — это делает агент после preflight.
-- Ветка и worktree на карточке — НАБЛЮДЕНИЕ, вычитанное из issue и событий
-  Gitea, а не намерение, заданное плагином.
-- Не трогает Hermes Kanban. Это другая система, и она этому CLI запрещена.
-
-## Выпуски
-
-**0.1 — доска, импорт, запуск.** Задачи хранятся локально, импортируются из
-Gitea по кнопке, карточки двигаются вручную, по кнопке «Начать» поднимается
-сессия с выбранной моделью. Синхронизация односторонняя: Gitea → канбан, в
-момент импорта и по кнопке обновления.
-
-**0.2 — автоперемещение.** События сессии агента, события Gitea, журнал
-переходов с источником. Инструмент `board_move` для агента пишется, но по
-умолчанию выключен — включается вместе с правкой скилла
-`gitea-project-workflow`.
-
-**0.3 — двусторонняя синхронизация.** Вебхуки Gitea, разрешение конфликтов по
-времени изменения, очередь повторов, деградация до опроса.
-
-## Состав 0.1
-
-| Issue | Репозиторий | Тема |
-|---|---|---|
-| G1 | dsh-gitea | Выставить сервис `gitea` наружу |
-| G2 | dsh-gitea | Техдолг: `gitea_worktree_add` зовёт bare git |
-| K1 | dsh-kanban | Каркас плагина и карточка настроек |
-| K2 | dsh-kanban | Хранилище задач |
-| K3 | dsh-kanban | HTTP-маршруты доски |
-| K4 | dsh-kanban | Импорт задачи из Gitea |
-| K5 | dsh-kanban | Экран доски |
-| K6 | dsh-kanban | Запуск работы по задаче |
-| K7 | dsh-kanban | Чип задачи в шапке чата |
-| K8 | dsh-kanban | Документация и релизный гейт 0.1 |
-
-Порядок: G1 → K1 → K2 → K3 → (K4, K5 параллельно) → K6 → K7 → K8.
-G2 независим и может идти когда угодно.
-
-## Структура файлов
-
-```
-lib/index.js        точка входа хоста: Config, apply, регистрация маршрутов
-lib/store.js        хранилище задач: схема, CRUD, дробный индекс
-lib/order.js        дробный индекс (чистая функция, без БД)
-lib/import.js       перенос issue Gitea в задачу доски
-lib/launcher.js     запуск сессии по задаче
-lib/routes.js       обработчики HTTP
-lib/client.js       браузерная половина: раздел доски, карточка настроек, чип
-test/*.test.mjs     тесты без харнесса и без сети
-```
-
-Разделение по ответственности, а не по слою. `order.js` отделён от `store.js`
-потому, что дробный индекс — единственная нетривиальная логика в хранилище и
-проверяется без БД вообще.
-
-## Проверенные интерфейсы ядра
-
-Ниже — реальные сигнатуры, снятые с исходников, а не пересказ. Исполнитель
-может опираться на них как есть.
-
-Создание сессии с выбранной моделью и первое сообщение:
-
-```js
-import { SessionId } from '@deepseek-ai/dsh-session'
-import { createUserMessage } from '@deepseek-ai/dsh-llm'
-
-const handle = await ctx.agents.create({
-  sessionId: SessionId(`kanban-${taskId}-${randomUUID()}`),
-  meta: { cwd },                       // ОБЯЗАТЕЛЬНО абсолютный путь
-  agentOptions: { provider, model },   // maxTokens необязателен
-})
-await handle.agent.whenIdle()
-handle.agent.followup(createUserMessage({
-  content,
-  source: { kind: 'plugin', plugin: 'dsh-kanban', form: 'task-start' },
-}))
-```
-
-- `ctx.agents.create(options)` возвращает `AgentHandle` с полями `agent` и
-  `dispose`. Живой образец — `dsh-messenger-gateway/lib/gateway.js:465`.
-- `meta.cwd` валидируется ядром: неабсолютный путь бросает исключение.
-- `agent.followup(message)` ставит обычный следующий ход и будит драйвер.
-- `agent.session.id` — идентификатор сессии, по нему карточка связывается с
-  чатом.
-- Модель по умолчанию берётся из сервиса `agentDefaultModel`; образец
-  разрешения провайдера и модели — `gateway.js:455`.
-
-События сессии, нужные в 0.2: `assistant/message`, `turn/end`,
-`approval/asked` (несёт `id`, имя инструмента, причину), `question/requested`.
-
-## Открытый технический риск
-
-`node:sqlite` — встроенный модуль Node, но он появился не во всех версиях.
-ПЕРВЫЙ шаг задачи K2 — проверить, что модуль есть в той версии Node, на которой
-крутится харнесс. Если модуля нет, хранилище делается на одном JSON-файле с
-атомарной записью (запись во временный файл рядом, затем `rename`), а схема
-таблиц из K2 переносится в форму объекта один-в-один. Дробный индекс и весь
-остальной план от выбора хранилища не зависят.
-
-Решение принимается фактом проверки, а не догадкой, и записывается в issue K2.

package/docs/plans/2026-09-07-quality-acceptance-gateway.md

@@ -1,25 +0,0 @@
-# План реализации: Human-in-the-Loop Quality & Acceptance Gateway (#205–#209)
-
-Пакетная реализация сквозного контура контроля качества и человеческой приёмки для `@goodandready/dsh-kanban`:
-- **#205**: DoD Acceptance Checklist с фиксацией доказательств (`board_checklist`)
-- **#206**: Структурированный отчёт выполнения задачи (`board_report`)
-- **#207**: Двусторонний цикл приёмки человеком (Accept / Send back with reason)
-- **#208**: Ветка комментариев к задаче и синхронизация с агентом (`board_comments`, `board_comment_add`)
-- **#209**: Протокольный шлюз запрета перевода задачи в Done агентом
-
-## 1. Архитектурные требования
-1. **Протокольный шлюз Done (#209)**: агент через инструмент `board_move` не может перевести задачу в `done`. Статус `done` может быть установлен только человеком.
-2. **Шлюз перехода в Review (#205)**: если в задаче заданы обязательные пункты Definition of Done, переход в `review` блокируется до закрытия всех обязательных пунктов с предоставлением evidence.
-3. **Отчёт выполнения (#206)**: агент формирует структурированный отчёт (`board_report`) с полями `summary`, `changed_files`, `checks_run`, `artifacts`, `risks`.
-4. **Приёмка и возврат (#207)**: в колонке `review` человек может нажать «Принять» (в `done`) или «Вернуть» (в `in-progress`) с обязательным указанием причины, которая инжектируется в следующую сессию агента.
-5. **Обсуждение задачи (#208)**: карточка содержит тред комментариев с поддержкой ролей `user` и `agent`, доступный через HTTP API и инструменты `board_comments`, `board_comment_add`.
-
-## 2. Пошаговые задачи
-- [ ] 1. Модель данных и миграции SQLite в `lib/store.js`.
-- [ ] 2. Инструменты агента `board_checklist`, `board_report`, `board_comments`, `board_comment_add`, валидаторы `board_move` в `lib/board-tool.js`.
-- [ ] 3. Регистрация инструментов в `lib/index.js`.
-- [ ] 4. Маршруты `/accept`, `/reject`, `/checklist`, `/report`, `/comments` в `lib/routes.js`.
-- [ ] 5. Инъекция замечаний возврата и DoD в `lib/launcher.js`.
-- [ ] 6. Пользовательский интерфейс Task Drawer и карточек в `lib/client.js`.
-- [ ] 7. Юнит-тесты: `test/checklist.test.mjs`, `test/report.test.mjs`, `test/acceptance.test.mjs`, `test/comments.test.mjs`.
-- [ ] 8. Актуализация `docs/design/DESIGN.md`.

package/docs/plans/2026-09-08-concurrency-safety.md

@@ -1,8 +0,0 @@
-# Implementation Plan: Vector 2 — Concurrency & Safety (#214, #216, #224)
-
-Implementation of resource protection, workspace claim boundaries, and database backup before snapshot import in `@goodandready/dsh-kanban` (v0.1.32).
-
-## Issues Scope
-1. **#214**: Global concurrent session limit and task queue (`maxConcurrentSessions`).
-2. **#216**: Project workspace claim boundaries (`workspaceClaimBoundaries`).
-3. **#224**: Automatic database safety backup before board snapshot import.

package/docs/plans/2026-09-08-diff-viewer-merge.md

@@ -1,7 +0,0 @@
-# Implementation Plan: Vector 3 — Git Diff / Commit Viewer & One-Click Merge (#211, #212)
-
-Implementation of in-board git diff viewer and one-click worktree merge in `@goodandready/dsh-kanban` (v0.1.33).
-
-## Issues Scope
-1. **#211**: In-drawer Git Diff and commits viewer for human acceptance.
-2. **#212**: One-click worktree branch merge upon acceptance (`--no-ff`) with automated cleanup.

package/docs/plans/2026-09-08-session-worktree-stability.md

@@ -1,33 +0,0 @@
-# План: Вектор 1 — Стабильность сессий и воркдеревьев (#227, #226, #213, #215)
-
-## 1. Контекст и цели
-Повышение отказоустойчивости жизненного цикла сессий задач в DSH Kanban:
-- Сохранение привязки сессии к проекту в левом сайдбаре DSH (meta.cwd = projectRoot) при изоляции в воркдереве (#227).
-- Возможность продолжить работу над задачей («↻ Продолжить / Resume») в существующем воркдереве без деструктивного сброса ветки (#226).
-- Игнорирование структурного шума субмодулей и gitlink drift в проверках чистоты воркдерева checkWorktreeDirty (#213).
-- Исключение дочерних сессий субагентов (invoke_subagent) из списка живых сессий и трекинга карточек (#215).
-
-## 2. Архитектурные изменения
-- **lib/worktree.js**:
-  - checkWorktreeDirty: вызов gitRunner(['status', '--porcelain', '--ignore-submodules=all'], worktreePath) для устранения ложного dirty-статуса от субмодулей.
-- **lib/launcher.js**:
-  - obtainAgent: meta.cwd фиксируется как projectRoot, meta.worktreePath = worktreePath.
-  - 
-  - liveSessions: фильтрация сессий с origin === 'subagent' или parentId !== undefined.
-- **lib/lifecycle.js**:
-  - handleSessionEvent: игнорирование событий от сессий-субагентов.
-- **lib/routes.js**:
-  - Эндпоинт POST /tasks/:id/resume.
-- **lib/index.js**:
-  - Регистрация маршрута /dsh-kanban/tasks/:id/resume.
-- **lib/client.js**:
-  - Кнопка «↻ Resume» в TaskDrawer.
-
-## 3. Верификация
-- Юнит-тесты: 	est/worktree-dirty.test.mjs, 	est/launcher-cwd.test.mjs, 	est/resume.test.mjs, 	est/subagent-filter.test.mjs.
-- Полный прогон 
-pm test и 
-pm run compat.
-- Проверка пакета 
-pm pack --dry-run --json.
-- Тест на MiniPC test runner через dsh-test-plugin.

package/docs/plans/2026-09-10-issue-238-settings-scope.md

@@ -1,13 +0,0 @@
-# Issue #238: Убрать settings.section fallback и перевести обращение к службам на ctx.get
-
-## Контекст
-Issue #238 (priority/low, type/tech-debt, scope/webui) указывает:
-1. Карточка настроек регистрирует запасной слот settings.section (строку в боковом списке настроек). Согласно дизайн-контракту и политике DSH-плагинов, боковой список настроек плоский и перегружен, а набор полей плагина должен жить исключительно как карточка внутри «Настройки → Плагины → Настройки плагинов» (settings.plugin.item).
-2. В коде обнаружено обращение ctx.llm вместо канонического ctx.get('llm'). Контекст Cordis оборачивается в прокси, и свойства-поля могут возвращать undefined, поэтому доступ к службам должен выполняться строго через ctx.get('...').
-
-## План работ
-- [ ] 1. Исправить вызовы ctx.llm на ctx.get('llm') в lib/index.js (GET /dsh-kanban/models).
-- [ ] 2. В lib/client.js убрать запасную регистрацию settings.section, оставив карточку только в слоте settings.plugin.item.
-- [ ] 3. Актуализировать тесты в test/board-ui.test.mjs и test/identity.test.mjs.
-- [ ] 4. Обновить docs/design/DESIGN.md (зафиксировать решение #238).
-- [ ] 5. Выполнить полный тестовый прогон npm test (все 651 тест) и npm run compat.