Skip to content

ol-bashkin/ts-harness

v0.3.0

OpenSpec workflow with a strategist, explicit pauses, independent review, and optional project agreements.

TS.harness

Плагин для Codex и Claude Code. Стратег ведёт доску изменений, запускает отдельные сессии и передаёт работу преемнику через HANDOVER.md. OPSX проводит каждый change через OpenSpec 1.12.0, согласование, реализацию и независимое ревью. Решения по этапам принимает владелец.

Установка

Codex

codex plugin marketplace add https://github.com/ol-bashkin/TS.harness.git
codex plugin add ts-harness@ts-harness

Открой новую сессию в рабочем дереве проекта. Набери $ и выбери ts-harness:opsx, затем укажи операцию и имя change. Для ревью в отдельной сессии выбери ts-harness:opsx-review.

Claude Code

claude plugin marketplace add https://github.com/ol-bashkin/TS.harness.git
claude plugin install ts-harness@ts-harness

В новой сессии в рабочем дереве проекта используй /ts-harness:opsx и передай операцию и имя change. Независимый ревьюер запускает /ts-harness:opsx-review в своей сессии.

Для локальной копии плагина обе команды marketplace add принимают путь к каталогу TS.harness.

Работа со стратегом

Открой сессию в корне проекта. В Codex выбери ts-harness:strategist через $, а в Claude Code введи /ts-harness:strategist. Для первой сессии попроси инициализировать доску и сформулировать ближайшую фазу. При повторном входе попроси восстановить состояние с диска. Передай цель, допустимый объём и условия приёмки первого change.

Стратег хранит состояние и решения владельца в .harness/board.json и показывает доску как таблицу. У каждого change своё рабочее дерево. Каждый исполнитель, ревьюер и проверяющий получает отдельную сессию и точное поручение на этап. Там, где доступны средства запуска отдельных чатов, стратег может использовать их. В терминале он может запустить отдельный процесс Codex или Claude Code. Такой запуск требует установленного и авторизованного клиента и использует его действующие настройки разрешений. Владелец также может открыть сессию сам по подготовленному поручению.

Попроси стратега «передай дела», чтобы он записал текущее состояние и следующий шаг в HANDOVER.md. Доска замораживается. Открой новую сессию стратега в том же проекте и попроси восстановить работу по записке. После сверки зарегистрируй и активируй преемника. Прежний стратег теряет право менять доску, а открытые исполнители продолжают свои этапы. Инструкции стратега

Доска, записка, поручения и журналы относятся к проекту, где запущен процесс. Храни их по правилам проекта. Для локальной пробы можно исключить файлы доски, журналы и HANDOVER.md через .git/info/exclude. Если команда делится состоянием через Git, проверяй список файлов перед публикацией. Ветка change, архив OpenSpec и запись о приёмке по-прежнему следуют правилам проекта.

Подготовка проекта

Работай из корня Git-репозитория с установленными Node.js 20.19+ и OpenSpec 1.12.0. Предпочтительный вариант — закрепить @fission-ai/openspec версии 1.12.0 в зависимостях разработки средствами проекта. На Windows используй установку в проект, чтобы OPSX запускал CLI напрямую через Node.js. Для npm:

npm install --save-dev --save-exact @fission-ai/openspec@1.12.0
npm exec --no -- openspec --version

Если проект ещё не использует OpenSpec, инициализируй его той же версией. Параметр --tools none оставляет вызов навыков плагину.

npm exec --no -- openspec init --tools none

Для проекта с существующим openspec/ используй текущие настройки и спеки. OPSX проверяет версию CLI перед вызовом. При отсутствии совместимой версии он указывает причину и ждёт установки. Документация OpenSpec 1.12.0

Договорённости по разработке

Чтобы включить профиль Vue / TypeScript, добавь .harness/project.json в корень репозитория.

{
  "profiles": ["vue-ts"]
}

Необязательное поле rules содержит пути к локальным Markdown-документам относительно корня, например "rules": ["docs/frontend-rules.md"]. Храни конфигурацию и эти документы в Git, чтобы они попали в рабочее дерево исполнителя и ревьюера. Если PRODUCT.md, DESIGN.md или другой контракт должен войти в контрольную сумму, укажи его в rules. Версии зависимостей и команды проверок берутся из проекта.

На паузе 1 OPSX фиксирует выбранные правила, их контрольную сумму и обязательные проверки. Исполнитель и ревьюер сверяют этот набор с принятым планом. Изменение правил возвращает change на обновление плана. Отсутствие .harness/project.json сохраняет обычный OPSX-процесс. Как загружаются правила

Один change

Заведи отдельное рабочее дерево для change. В первом запросе укажи цель, границы правок, ожидаемый результат и проверки. В Codex выбери ts-harness:opsx и введи propose add-summary с описанием задачи. В Claude Code это выглядит так:

/ts-harness:opsx propose add-summary
Добавь команду summary, которая печатает число записей. Сохрани формат входных данных. Приёмка — тест для пустого и непустого списка.
ЭтапЧто передаётся на следующий шаг
proposeАртефакты OpenSpec и pause1.md. Владелец принимает план и явно поручает apply.
applyРеализация, результаты проверок и pause2.md с ревизией для ревью.
Отдельное ревьюНовый чат с opsx-review получает change, базу и ревизию из pause2.md. Ревьюер записывает вывод в review.md.
fixЕсли есть замечания, исполнитель разбирает их в pauseR.md. Правки начинаются после поручения владельца. Обновлённая ревизия проходит отдельное повторное ревью.
archiveПосле принятия результата владелец поручает архивирование. OPSX валидирует change, переносит принятые требования в канонические спеки и проверяет результат.

Отчёты пауз лежат рядом с артефактами в каталоге change. По ним можно продолжить работу в новой сессии. Полные журналы остаются локально, а в отчёт идут команды, результаты и ревизия. Публикация ветки, PR и слияние следуют разрешениям проекта и поручению владельца.

explore помогает разобраться в задаче до плана. update продолжает работу над артефактами существующего change. sync переносит дельты в канонические спеки отдельным этапом по поручению владельца.

Проверка пакета

В корне TS.harness запусти node --test test/*.test.mjs с OpenSpec 1.12.0 в PATH. Проверки проходят цикл OpenSpec до архива, запуск отдельного процесса на тестовом клиенте и передачу замороженной доски между сессиями. Паузы и ревью задаются инструкциями для агента. Права на Git и порядок публикации задаёт проект.