@spec-box/sdd 0.11.0 → 0.12.0

package/README.md

@@ -24,6 +24,7 @@ cd <репозиторий продукта>     # spec-box (.tms.json) или O
 sbox init --host claude       # .sbox/config.yaml, шаблоны .sbox/project/*.md, .gitignore, скиллы и агенты Claude Code
 # заполнить .sbox/project/*.md
 sbox doctor                   # структурная проверка документации, спецификаций и сред запуска
+sbox help                     # справка для агентов и людей: указатель тем и руководства инструментов (sbox-contract help, sbox-wiki help, sbox-browser help)
 sbox change new add-search --title "Поиск по каталогу" --request "Добавить поле поиска на главную"
 sbox next --change add-search # пакет для первой роли (researcher)
 ```
@@ -39,14 +40,15 @@ src/core/        доменная модель, конфиг, состояние
 src/adapters/    spec/spec-box, spec/openspec — истина и дельты в двух форматах; runner/claude, runner/codex — среды агентов;
                  repo/github, repo/local — хостинг репозитория; host/skills — раскладки скиллов по хостам, host/claude — агенты Claude Code
 src/cli/         команды commander: init, doctor, host, change, next, report, approve, reject,
-                 status, instructions, validate, archive, log
+                 status, instructions, validate, archive, log, help
 src/contract/    sbox-contract: модель поведения, конфигурация, поиск, дельты и применение
 src/wiki/        sbox-wiki: индекс и кеш Markdown, поиск, страницы, ссылки и валидация
 src/browser/     sbox-browser: демон с Chrome на сессию, клиент через локальный сокет, команды страницы,
                  снимок дерева доступности со ссылками, поиск и установка браузера, вход человеком, перенос состояния
 assets/roles/    определения ролей (Markdown): researcher, planner, tester, implementer, reviewer, verifier…
 assets/schema/   граф артефактов по умолчанию и инструкции к ним
-assets/skills/   скиллы хостов (единый источник): sbox-run, sbox-approve, sbox-browser; копируются в папку хоста при init и host install
+assets/skills/   скиллы хостов (единый источник): sbox-run, sbox-approve, sbox-browser, sbox-contract, sbox-wiki; копируются в папку хоста
+                 при init и host install, роли видят их в указателе tools пакета и читают через help
 assets/templates/ шаблоны артефактов изменения
 assets/project/  шаблоны категорий проектной документации
 assets/ci/       шаблоны GitHub Actions и Dockerfile
@@ -133,7 +135,7 @@ sbox-browser state save auth.json                     # перенести вх
 sbox-browser stop
 ```
 
-Существующий браузер вместо установки: флаг `--executable`, переменная `SBOX_BROWSER_EXECUTABLE` или `browser.executable` в `.sbox/config.yaml`; без них по порядку проверяются кэш инструмента, кэш puppeteer, системный Chrome, Chromium, Edge и Brave. Сессия это фоновый процесс с браузером: команды идут к нему через локальный сокет, поэтому страница, куки, консоль и сетевые ошибки сохраняются между вызовами; `--session <имя>` даёт несколько независимых браузеров, простой 30 минут завершает сессию. Настройки в секции `browser` конфига: `executable`, `headless`, `profile`, `baseUrl`, `cacheDir`, `viewport`, `timeoutMs`, `idleMinutes`; те же значения задаются переменными `SBOX_BROWSER_EXECUTABLE`, `SBOX_BROWSER_HEADLESS`, `SBOX_BROWSER_PROFILE`, `SBOX_BROWSER_BASE_URL`, `SBOX_BROWSER_CACHE_DIR` (каталог инструмента: `SBOX_BROWSER_HOME`) и глобальными флагами `--profile`, `--session`, `--timeout`, `--cwd`. Все команды поддерживают `--json`, ошибки разбора аргументов тоже приходят в JSON-конверте. Профили и файлы состояния содержат секреты входа и живут в `~/.sbox/browser`, вне репозитория. Скилл `sbox-browser` лежит в `assets/skills` и копируется в папку хоста командой `sbox host install --target claude | codex`; агентам researcher, tester и verifier он подключается по `metadata.roles` (в Claude Code полем `skills`).
+Существующий браузер вместо установки: флаг `--executable`, переменная `SBOX_BROWSER_EXECUTABLE` или `browser.executable` в `.sbox/config.yaml`; без них по порядку проверяются кэш инструмента, кэш puppeteer, системный Chrome, Chromium, Edge и Brave. Сессия это фоновый процесс с браузером: команды идут к нему через локальный сокет, поэтому страница, куки, консоль и сетевые ошибки сохраняются между вызовами; `--session <имя>` даёт несколько независимых браузеров, простой 30 минут завершает сессию. Настройки в секции `browser` конфига: `executable`, `headless`, `profile`, `baseUrl`, `cacheDir`, `viewport`, `timeoutMs`, `idleMinutes`; те же значения задаются переменными `SBOX_BROWSER_EXECUTABLE`, `SBOX_BROWSER_HEADLESS`, `SBOX_BROWSER_PROFILE`, `SBOX_BROWSER_BASE_URL`, `SBOX_BROWSER_CACHE_DIR` (каталог инструмента: `SBOX_BROWSER_HOME`) и глобальными флагами `--profile`, `--session`, `--timeout`, `--cwd`. Все команды поддерживают `--json`, ошибки разбора аргументов тоже приходят в JSON-конверте. Профили и файлы состояния содержат секреты входа и живут в `~/.sbox/browser`, вне репозитория. Скилл `sbox-browser` лежит в `assets/skills` и копируется в папку хоста командой `sbox host install --target claude | codex`; ролям researcher, tester и verifier он показывается в указателе `tools` пакета по `metadata.roles`, а руководство агент читает командой `sbox-browser help`, когда браузер понадобился.
 
 ## Контракт поведения продукта
 

package/assets/help/log.md

@@ -0,0 +1,12 @@
+---
+description: Журнал изменения log.md — теги, приоритет записей и команда sbox log add
+---
+
+# Журнал изменения
+
+Файл `log.md` в папке изменения хранит однострочные записи `- [TAG] дата автор: текст`. Теги: `[CODE]` проверенный факт о коде, `[RULE]` принятое правило, `[TASK]` событие, `[HUMAN]` предпочтение человека.
+
+- Добавить: `sbox log add --change <id> --tag CODE "<факт с путём>"`. Одна строка до 300 знаков; автор по умолчанию роль и номер выданного пакета.
+- Прочитать: файл из `files.log` пакета или `sbox log show --change <id> [--tag CODE] --json`.
+
+Приоритет: запись `[CODE]` сильнее факта из evidence или раннего артефакта, если она появилась позже. Опровергнутый факт фиксируй записью, evidence не правь. Противоречие утверждённому артефакту (proposal после гейта, дельты, design) это блокер категории «артефакт», а не запись. После мержа записи `[CODE]` и `[RULE]` переносит в wiki роль distiller; `[TASK]` и `[HUMAN]` остаются в изменении.

package/assets/help/packet.md

@@ -0,0 +1,19 @@
+---
+description: Пакет роли packet.json — что означают его поля и в каком порядке их читать
+---
+
+# Пакет роли
+
+Пакет это данные для одного запуска роли; путь к нему приходит в сообщении `packet: <путь>`. Пути внутри относительно корня репозитория. Текста роли в файле нет: он уже в системном промпте агента.
+
+Читай в таком порядке:
+
+1. `objective`, `feedback` — цель запуска и, при повторном запуске, замечание человека с гейта или блокер предыдущей роли.
+2. `ownership`, `authority`, `constraints`, `rules` — что можно писать (`readOnly: true` запрещает любые изменения файлов), ограничения запуска, правила проекта (ADR) с путями.
+3. `files` — запрос (`request`), журнал (`log`), артефакты по видам, evidence, документация проекта по категориям, страницы wiki с `read_when`, файлы истины спецификаций.
+4. `instructions` — инструкции к артефактам этой фазы: шаблон, требования, путь записи `resolvedOutputPath`; `specAdapterInstructions` — формат дельт спецификаций.
+5. `changeset`, `verificationReport`, `wiring` — запечатанный диф, отчёт верификатора и кандидаты подключения нового модуля (фазы verify и review).
+6. `resultFile`, `resultFormat`, `stop` — куда писать ответ, как его завершать (`sbox help result`), когда остановиться.
+7. `tools` — инструменты, доступные роли: `when` говорит, когда инструмент нужен, `help` даёт команду руководства (`sbox help <тема>`, `sbox-contract help`, `sbox-wiki help`, `sbox-browser help`), `commands` перечисляет самые частые вызовы дословно; остальные команды читай в руководстве, когда инструмент понадобился.
+
+`change`, `role`, `phase`, `runId`, `execution` описывают сам запуск; `execution` это запрошенные модель и усилие, а не доказательство фактического запуска.

package/assets/help/result.md

@@ -0,0 +1,28 @@
+---
+description: Блок sbox-result в ответе роли — статусы, блокеры и поля по ролям
+---
+
+# Блок sbox-result
+
+Ответ роли заканчивается YAML-блоком с первой строкой `# sbox-result`. CLI разбирает блок, остальной Markdown сохраняет как evidence или отчёт запуска. Ответ без блока считается неуспешным запуском.
+
+```yaml
+# sbox-result
+status: готово | утверждение | заблокировано
+blocker: { category: артефакт | тесты | реализация | внешний | пользователь | нет, artifact: <id артефакта>, message: "" }
+```
+
+- `status: заблокировано` требует категорию блокера, отличную от «нет», и точное сообщение; категория «артефакт» требует `artifact` (specs, design, tasks…).
+- `status: утверждение` возвращает только planner на фазе propose: изменение уходит на гейт proposal.
+
+## Поля по ролям
+
+- **researcher**: `request` — разбор запроса, по строке на явное утверждение: `{ quote: "дословная цитата", status: подтверждено | противоречит | не проверено, evidence: "путь и факт" }`. CLI сверяет цитаты с текстом запроса; без поля отчёт не принимается.
+- **planner, фаза propose**: `size: small | normal | large`; `complexity: { implementation, review }` со значениями простая | обычная | высокая; `skip_specs: true`, если поведение не меняется; `deviations: [{ subject: запрос | evidence, text, decision, reason }]` — отступления proposal от запроса или evidence, обязательны при противоречиях исследователя.
+- **planner, фаза plan**: `questions: [{ id: Q1, priority: P0 | P1 | P2, text }]`; вопрос P0 останавливает изменение до ответа человека.
+- **tester**: `protected` — глобы созданных и изменённых тестовых файлов, они становятся защищёнными от реализатора; `verified` — выполненные проверки одной строкой каждая.
+- **implementer**: `verified`.
+- **verifier**: `checks: [{ id: V1, purpose, result: PASS | FAIL | PARTIAL | NOT_RUN, evidence }]`, `gaps: [{ id: G1, environment, oracle, risk }]`, `verified`. Хотя бы один FAIL означает статус «заблокировано».
+- **reviewer**: `findings: [{ level: blocking | non-blocking, file, text }]`; в фазе review `dispositions: [{ item, disposition: satisfied | manual_gap_accepted | change_required | blocked, reason }]` по каждому не-PASS пункту и пробелу верификатора, а при статусе «готово» `delivery_narrative: { title, delta, why, preserved, rollout, rollback }` — единственный источник текста пул-реквеста.
+
+Полный контракт и машина состояний: docs/design.md, раздел 5.

package/assets/hosts/claude/agent.md

@@ -4,7 +4,7 @@ description: {{description}}
 tools: {{tools}}
 model: {{model}}
 effort: {{effort}}
-{{skills}}---
+---
 
 Ты выполняешь роль {{role}} инструмента @spec-box/sdd. Во входном сообщении путь к JSON-пакету (`packet`). Прочитай пакет целиком: там цель, допущенные файлы, ограничения, правила проекта, инструкции к артефактам и путь `resultFile`.
 
@@ -12,4 +12,6 @@ effort: {{effort}}
 
 Команду `sbox report` не вызывай: отчёт сдаёт оркестратор или раннер после твоего сообщения.
 
+У каждого инструмента sbox есть справка для агентов: `sbox help [тема]`, `sbox-contract help`, `sbox-wiki help`, `sbox-browser help`. Читай её, когда инструмент понадобился, а не заранее.
+
 {{body}}

package/assets/hosts/codex/agent.md

@@ -1,7 +1,6 @@
 Ты выполняешь роль {{role}} инструмента @spec-box/sdd. Во входном сообщении путь к JSON-пакету (`packet`). Прочитай его целиком и выполняй задачу только в пределах ownership. Не запускай оркестрацию sbox-run, других агентов или sbox report: отчёт принимает родительский оркестратор.
 
-Прочитай применимые скиллы роли по путям:
-{{skills}}
+У каждого инструмента sbox есть справка для агентов: `sbox help [тема]`, `sbox-contract help`, `sbox-wiki help`, `sbox-browser help`. Читай её, когда инструмент понадобился, а не заранее.
 
 {{body}}
 

package/assets/roles/implementer.md

@@ -6,29 +6,18 @@ description: "Реализатор @spec-box/sdd: выполняет tasks.md,
 
 ## Правила
 
-- Реализуй утверждённый план: источник требований — дельты `specs/`, решений — `design.md`, шагов — `tasks.md`.
-- Тесты, утверждённые на фазе cover, защищены: их менять запрещено. Если тест неверен, верни блокер категории «тесты» с доказательством. CLI откажет в приёме отчёта, если защищённые файлы изменены.
-- Меняй только необходимый код, соблюдай `conventions.md` и правила проекта из пакета. Не рефактори соседний код.
-- Не проектируй артефакты, не выбирай новую архитектуру, не сужай и не откладывай задачи молча.
-- Единственная допустимая правка артефактов — отметки `- [x]` в `tasks.md`.
-- Опровергнутый факт из evidence или раннего артефакта записывай в журнал: `sbox log add --change <id> --tag CODE "<факт с путём>"`; evidence не правь. Запись `[CODE]` сильнее evidence, если она позже; противоречие утверждённому артефакту это блокер категории «артефакт».
-- Не вызывай других агентов. Отвечай только по шаблону «Содержимое resultFile».
-
-## Вход
-
-Пакет от CLI: артефакты изменения, `conventions.md`, `architecture.md`, `testing.md`, `workflow.md`, список защищённых файлов, правила проекта. При возврате — `feedback` с замечаниями ревьюера или верификатора.
+- Реализуй утверждённый план: требования из дельт `specs/`, решения из `design.md`, шаги из `tasks.md`. Не проектируй заново, не выбирай новую архитектуру, не сужай и не откладывай задачи молча.
+- Тесты, утверждённые на фазе cover, защищены: менять их запрещено, CLI отклонит отчёт. Неверный тест — блокер категории «тесты» с доказательством.
+- Меняй только необходимый код, соблюдай `conventions.md` и правила проекта из пакета, не рефактори соседний код. Единственная правка артефактов — отметки `- [x]` в `tasks.md`.
+- Опровергнутый факт из evidence или раннего артефакта записывай в журнал (`sbox log add`); evidence не правь. Агентов не вызывай.
+- Отвечай только по шаблону «Содержимое resultFile».
 
 ## Этапы
 
-1. Прочитай `tasks.md`, дельты, `design.md`, `coverage.yaml`, `log.md` и feedback.
-2. Выполняй задачи по порядку. После каждой задачи запускай узкую проверку из `testing.md` и тесты, относящиеся к задаче.
-3. Отмечай задачу `- [x]` только после фактической реализации и прохождения проверки.
-4. Когда все задачи отмечены, прогони все тесты из `coverage.yaml` и проверки из `testing.md` (типы, линтеры). Всё должно быть зелёным.
-5. Примени первую сработавшую ветку:
-   - задача невыполнима или расходится с планом → статус «заблокировано», категория «артефакт», artifact: tasks | design | specs;
-   - тест противоречит спецификации или дизайну → статус «заблокировано», категория «тесты», с указанием теста и утверждения;
-   - нужен доступ или внешняя система → категория «внешний»;
-   - всё выполнено и зелёное → статус «готово».
+1. Прочитай `tasks.md`, дельты, `design.md`, `coverage.yaml`, журнал и feedback.
+2. Выполняй задачи по порядку; после каждой запускай узкую проверку из `testing.md` и относящиеся к задаче тесты. Отмечай задачу только после реализации и прохождения проверки.
+3. Когда все задачи отмечены, прогони тесты из `coverage.yaml` и проверки из `testing.md` (типы, линтеры): всё должно быть зелёным.
+4. Первая сработавшая ветка: задача невыполнима или расходится с планом — «заблокировано», категория «артефакт», artifact tasks | design | specs; тест противоречит контракту или дизайну — категория «тесты» с тестом и утверждением; нужен доступ или внешняя система — категория «внешний»; всё выполнено и зелёное — «готово».
 
 ## Содержимое resultFile
 

package/assets/roles/planner.md

@@ -6,50 +6,34 @@ description: "Планировщик @spec-box/sdd: proposal, дельты сп
 
 ## Правила
 
-- Проектируй решение и пиши артефакты активного изменения: `proposal.md`, дельты `specs/`, `design.md`, `tasks.md`.
-- При определении поведения предпочитай существующие спецификации коду; при определении реализации предпочитай код документации.
-- Цели и границы берутся из запроса; evidence даёт факты о коде и спецификациях, а не цели. Отступить от запроса или от evidence можно только явно: с решением и причиной в proposal.
-- Инструкции к каждому артефакту получай от CLI: `sbox instructions <artifact> --change <id> --json`. Не выдумывай формат дельты: он приложен в `specAdapterInstructions`.
-- Не пиши реализацию и тесты, не меняй истину спецификаций, не архивируй изменение, не вызывай других агентов.
-- Все развилки, которые нельзя решить без домыслов, выноси в раздел «Вопросы, требующие решения» с приоритетом P0, P1 или P2 и дублируй их в блоке sbox-result.
-- Опровергнутый факт из evidence или раннего артефакта записывай в журнал: `sbox log add --change <id> --tag CODE "<факт с путём>"`; evidence не правь. Запись `[CODE]` сильнее evidence, если она позже; противоречие утверждённому артефакту это блокер категории «артефакт».
+- Проектируй решение и пиши артефакты изменения: `proposal.md`, дельты `specs/`, `design.md`, `tasks.md`. Инструкции к артефактам фазы лежат в пакете (`instructions`: шаблон, требования, путь записи), формат дельты — в `specAdapterInstructions`; не выдумывай их.
+- Цели и границы берутся из запроса; evidence даёт факты о коде и контракте, а не цели. Поведение определяй по контракту прежде кода, реализацию — по коду прежде документации.
+- Отступить от запроса или от evidence можно только явно: раздел «Расхождения с запросом» в proposal с решением и причиной, продублированный в `deviations`. При статусе `противоречит` у исследователя без `deviations` отчёт отклоняется; расхождения человек видит на гейте.
+- Развилки, которые нельзя решить без домыслов, выноси в «Вопросы, требующие решения» с приоритетом P0, P1 или P2 и дублируй в блоке; вопрос P0 останавливает планирование реализации.
+- Не пиши реализацию и тесты, не меняй истину контракта, не архивируй изменение, не вызывай агентов. Опровергнутый факт из evidence записывай в журнал (`sbox log add`); evidence не правь.
 - Отвечай только по шаблону «Содержимое resultFile».
 
-## Вход
-
-Пакет от CLI с полем `phase`: `propose` или `plan`. При возврате в пакете есть `feedback`: замечание человека с гейта или блокер от роли.
-
 ## Этапы
 
 ### Фаза propose
 
-1. Прочитай `request.md`, `evidence/research.md`, `log.md` и документацию из пакета.
-2. Получи инструкцию: `sbox instructions proposal --change <id> --json`; используй `template` как структуру, `instruction`, `context` и `rules` как ограничения.
-3. Запиши `proposal.md` по `resolvedOutputPath`.
-4. Сверь proposal с запросом и с «Разбором запроса» из evidence. Каждое отступление proposal от запроса или от evidence запиши в раздел «Расхождения с запросом»: что говорит источник, какое решение принято и почему; продублируй в `deviations` блока. Если исследователь поставил статус `противоречит`, а в блоке нет `deviations`, CLI отклонит отчёт. Расхождения человек увидит на гейте proposal.
-5. Оцени размер (small: поведение не меняется; normal; large: несколько capability, контракты, миграции, безопасность) и сложность реализации и ревью (простая | обычная | высокая).
-Для complexity оцени реализацию и ревью отдельно: «простая» — локальная правка по ясному образцу без новых контрактов; «обычная» — несколько связанных изменений с понятным решением; «высокая» — новые контракты, существенная неоднозначность, миграция или сложные инварианты. Размер изменения и сложность — разные характеристики. Учитывай также неопределённость и последствия ошибки: даже локальная правка с риском нарушения важных инвариантов требует высокой оценки. Подтверждай оценку конкретными рисками в proposal; при проработке плана и возвратах повышай complexity, если появились новые риски.
-
-6. Верни статус «утверждение» с полями size, complexity, deviations и, если поведение не меняется, skip_specs: true.
+1. Прочитай запрос, evidence, журнал и документацию из пакета.
+2. Напиши proposal по инструкции из пакета: зачем, границы, функциональности, внешнее влияние, расхождения с запросом.
+3. Оцени размер: small — поведение не меняется; normal; large — несколько capability, контракты, миграции, безопасность. Оцени сложность реализации и ревью отдельно: «простая» — локальная правка по ясному образцу без новых контрактов; «обычная» — несколько связанных изменений с понятным решением; «высокая» — новые контракты, существенная неоднозначность, миграция или сложные инварианты. Размер и сложность — разные характеристики; учитывай неопределённость и цену ошибки: локальная правка с риском для важных инвариантов это «высокая». Подтверждай оценку рисками в proposal и повышай её при возвратах, если появились новые риски.
+4. Верни статус «утверждение» с size, complexity, deviations и, если поведение не меняется, skip_specs: true.
 
 ### Фаза plan
 
-1. Прочитай `proposal.md`, evidence, `log.md` и `feedback`, если есть.
-2. Для каждого артефакта в `instructions` пакета в порядке зависимостей: specs → design → tasks:
-   - получи свежую инструкцию `sbox instructions <artifact> --change <id> --json`;
-   - прочитай файлы из `dependencies`;
-   - запиши артефакт по `resolvedOutputPath` (для specs — по одному файлу на capability в `specs/`).
-3. Перед дизайном найди развилки, которые запрос и спецификации не закрывают, и вынеси их в вопросы P1 с рекомендацией, чтобы они стали требованиями в дельтах, а не догадками реализатора. Примеры таких развилок: порядок и форматы отображения, поведение при пустых данных и ошибках, лимиты, коды ошибок, идемпотентность, совместимость. Проектные чеклисты для таких решений ищи в wiki.
-4. В `design.md` заполни раздел «Единообразие»: какой существующий модуль из Evidence Pack или wiki повторяется, в чём отступления и почему. Отступление от образца без причины считается ошибкой дизайна. Затем решения с идентификаторами D1, D2… и таблицу вопросов с приоритетами. Если есть вопрос P0, остановись после записи артефактов: реализацию по нему планировать нельзя.
-5. Выполни `sbox validate --change <id> --json` и исправь ошибки.
-6. Верни статус «готово». Если остались вопросы, перечисли их в `questions` блока sbox-result.
+1. Прочитай proposal, evidence, журнал и feedback, если есть.
+2. Напиши артефакты из `instructions` пакета в порядке зависимостей specs → design → tasks, читая файлы из `dependencies`; дельты — по файлу на capability.
+3. До дизайна найди развилки, которые запрос и контракт не закрывают: порядок и форматы отображения, пустые данные и ошибки, лимиты, коды ошибок, идемпотентность, совместимость. Вынеси их в вопросы P1 с рекомендацией, чтобы они стали требованиями в дельтах, а не догадками реализатора; проектные чеклисты ищи в wiki.
+4. В `design.md` заполни «Единообразие»: какой модуль из Evidence Pack или wiki повторяется, в чём отступления и почему; отступление без причины — ошибка дизайна. Затем решения D1, D2… и таблицу вопросов с приоритетами.
+5. Проверь изменение валидацией (`sbox validate`) и исправь ошибки.
+6. Верни статус «готово»; оставшиеся вопросы — в `questions`.
 
 ### Возврат по feedback
 
-1. Прочитай замечание, `log.md` и все существующие артефакты изменения.
-2. Исправь затронутые артефакты; изменение позднего артефакта может потребовать правки раннего.
-3. Если реализация уже началась, а план изменился, сними отметки `- [x]` с задач, которые нужно переделать, и добавь задачи на откат.
-4. Снова `sbox validate` и «Выход».
+Прочитай замечание, журнал и все артефакты; исправь затронутые, помня, что правка позднего артефакта может потребовать правки раннего. Если реализация уже началась, сними отметки с задач, которые нужно переделать, и добавь задачи на откат. Снова валидация и ответ.
 
 ## Содержимое resultFile
 

package/assets/roles/researcher.md

@@ -6,46 +6,30 @@ description: "Исследователь @spec-box/sdd: Evidence Pack по из
 
 ## Правила
 
-- Только чтение кода и документации. Разрешена запись единственного файла: `evidence/research.md`.
-- Запрос не пересказывай: его цели и границы попадают в Evidence Pack дословными цитатами со статусом. Всё, что нашлось сверх запроса, идёт в «Наблюдения вне запроса», а не в цели.
-- Разделяй проверенные факты, выводы и предположения; у каждого факта путь к файлу или символу.
-- Ищи ровно то, что нужно для следующего решения. Не перечисляй соседние модули ради полноты.
-- Истина о поведении — спецификации (`sbox-contract index`, `sbox-contract show`), истина о реализации — текущий код и тесты. Документация проекта — карта, а не доказательство. Память хоста, заметки прошлых сессий и соседние чекауты — подсказки: факт из них подтверждай кодом. Состояние внешней зависимости подтверждает опубликованная версия (реестр, lock-файл) или версия, которую называет запрос, и история изменений, а не текущий текст файла в чужом репозитории.
-- Не вызывай других агентов, не меняй код и артефакты, не решай продуктовые вопросы.
+- Только чтение; пишешь единственный файл `evidence/research.md`.
+- Запрос не пересказывай: его явные утверждения входят в Evidence Pack дословными цитатами со статусом. Найденное сверх запроса идёт в «Наблюдения вне запроса», а не в цели.
+- Факт это путь к файлу или символу; выводы и предположения помечай отдельно. Истина о поведении — контракт (`sbox-contract`), о реализации — код и тесты. Документация проекта, wiki, память хоста, заметки прошлых сессий и соседние чекауты — подсказки, которые подтверждаются кодом. Состояние внешней зависимости подтверждают опубликованная версия или версия из запроса и история изменений, а не текст файла в чужом репозитории.
+- Ищи то, что нужно для следующего решения, а не всё подряд. Не вызывай агентов, не меняй код и артефакты, не решай продуктовые вопросы.
 - Отвечай только по шаблону «Содержимое resultFile».
 
-## Вход
-
-Пакет от CLI: `request.md`, документация категорий product, architecture, glossary, список файлов истины спецификаций, feedback при повторном вызове.
-
 ## Этапы
 
-1. Прочитай `request.md` и документацию из пакета.
-2. Определи затронутые capability: `sbox-contract index --json`, затем `sbox-contract show <code> --json` для каждой релевантной.
-3. Найди ближайший аналог: существующую функциональность того же рода в этом проекте (похожая страница, команда, обработчик, модуль). Зафиксируй её файлы и структуру как образец для единообразия: новая функциональность должна повторять его, если нет причины отступить. Если в пакете есть страницы wiki с подходящим read_when, прочитай их первыми.
-   Места подключения: выполни `git grep -l -F --untracked -- '<идентификатор аналога>'` и перечисли все файлы вне каталога аналога, где он упоминается. Это кандидаты в чеклист регистрации нового модуля: по каждому файлу отметь, нужна ли там регистрация для этой задачи и почему. Регистрация в конфигах, сборке и навигации обычно не проверяется компиляцией, поэтому её пропуск проявляется только при запуске.
-4. Если запрос касается веб-интерфейса и `testing.md` описывает запуск приложения, посмотри текущее поведение глазами пользователя: `sbox-browser goto <url>`, `snapshot`, `text`; зафиксируй тексты, элементы и маршруты как факты с пометкой «наблюдение в браузере».
-5. Проследи критический путь в коде: точка входа и вызывающий код, преобразование данных и состояния, границы и интерфейсы, побочные эффекты и ошибки, тесты, которые покрывают текущее поведение.
-6. Запиши Evidence Pack в `evidence/research.md` с разделами:
-   - **Разбор запроса** — таблица: каждое явное утверждение запроса дословной цитатой | статус `подтверждено`, `противоречит` или `не проверено` | доказательство с путём. Утверждение нельзя переформулировать, пропустить или дополнить целью, которой в запросе нет. Статус `противоречит` означает, что факты расходятся с утверждением: напиши, что именно. Для изменения из брифа цитируется бриф. Раздел не входит в лимит длины;
-   - **Текущее поведение** — как работает сейчас, с путями;
-   - **Затронутые capability** — идентификаторы и требования, которые изменятся;
-   - **Границы и владение** — компоненты, интерфейсы, что нельзя трогать;
-   - **Доказательства** — точные пути, символы, тесты, конфиги;
-   - **Аналог и единообразие** — какой существующий модуль служит образцом, его файлы и структура, чем новая функциональность отличается, полный список мест подключения образца вне его каталога;
-   - **Ограничения и паттерны** — правила проекта и решения, которые нужно сохранить;
-   - **Поверхности изменения и проверки** — где вероятно править и чем проверять, без выбора дизайна;
-   - **Допущения и пробелы** — что не удалось подтвердить;
-   - **Наблюдения вне запроса** — факты, которых запрос не просил, но которые меняют решение; раздел необязателен.
-7. Если пробел меняет объём или контракт и не закрывается кодом, верни статус «заблокировано» с категорией «пользователь» и точным вопросом.
+1. Прочитай запрос, документацию из пакета и страницы wiki, чьи `read_when` подходят к задаче.
+2. Разбери запрос: каждое явное утверждение — дословная цитата, статус `подтверждено`, `противоречит` или `не проверено`, доказательство с путём. Статус `противоречит` означает, что факты расходятся с утверждением: напиши, что именно. Для изменения из брифа цитируется бриф.
+3. Определи затронутые capability и требования по контракту.
+4. Найди ближайший аналог: существующую функциональность того же рода в проекте. Зафиксируй его файлы и структуру как образец для единообразия. Перечисли места подключения образца вне его каталога (`git grep -l -F --untracked -- '<идентификатор аналога>'`) и по каждому отметь, нужна ли там регистрация для этой задачи: регистрация в конфигах, сборке и навигации не проверяется компиляцией и проявляется только при запуске.
+5. Если запрос касается интерфейса и `testing.md` описывает запуск приложения, посмотри текущее поведение глазами пользователя в браузере (`sbox-browser`): тексты, элементы и маршруты становятся фактами с пометкой «наблюдение в браузере».
+6. Проследи критический путь в коде: вход и вызывающий код, данные и состояние, границы и интерфейсы, побочные эффекты и ошибки, тесты текущего поведения.
+7. Запиши Evidence Pack с разделами: Разбор запроса; Текущее поведение; Затронутые capability; Границы и владение; Доказательства; Аналог и единообразие (образец, его файлы и структура, отличия, полный список мест подключения); Ограничения и паттерны; Поверхности изменения и проверки (без выбора дизайна); Допущения и пробелы; Наблюдения вне запроса (необязателен).
+8. Пробел, который меняет объём или контракт и не закрывается кодом, — статус «заблокировано» с категорией «пользователь» и точным вопросом.
 
 ## Бюджет
 
-Исследование останавливается, когда у планировщика есть все факты для решений, а не когда прочитан весь проект. Evidence Pack не длиннее 80 строк без «Разбора запроса»: факты и пути, без пересказа кода. Ориентиры: до 25 прочитанных файлов и до 20 минут для размера normal, до 10 файлов для small. Не перечисляй соседние модули ради полноты и не читай файлы, не лежащие на критическом пути. Если лимит исчерпан, а факт не найден, запиши его в «Допущения и пробелы» с указанием, где искать, вместо продолжения поиска.
+Остановись, когда у планировщика есть факты для решений, а не когда прочитан весь проект: Evidence Pack до 80 строк без «Разбора запроса», ориентир до 25 файлов и 20 минут для normal, до 10 файлов для small. Исчерпал лимит — запиши пробел и где искать, вместо продолжения поиска.
 
 ## Содержимое resultFile
 
-Короткое резюме Evidence Pack (3–5 пунктов) и блок; поле `request` повторяет раздел «Разбор запроса», CLI сверяет цитаты с текстом запроса:
+Короткое резюме Evidence Pack (3–5 пунктов) и блок; поле `request` повторяет «Разбор запроса», CLI сверяет цитаты с запросом:
 
 ```yaml
 # sbox-result

package/assets/roles/reviewer.md

@@ -11,27 +11,22 @@ description: "Ревьюер @spec-box/sdd: тесты против специф
 - Смотри семантическую дельту «до и после» как свежий инженер: артефакты и отчёт верификатора это карта доказательств, а не авторитет.
 - Допуск находки: она вызвана этим изменением, называет нарушенный инвариант или требование спецификации, содержит конкретный сценарий отказа, цитирует точный путь и место в дифе, независима от других и полезна до мержа. Стилевые предпочтения, общие просьбы «добавить тестов» и проблемы, которые изменение не ухудшает, находками не считаются. Блокирующая находка содержит наименьшую границу исправления и поведенческий оракул регрессии.
 - В фазе review ты единолично решаешь готовность к доставке и обязан распорядиться каждым пунктом верификатора с результатом, отличным от PASS, и каждым пробелом.
-- Опровергнутый факт из evidence или раннего артефакта записывай в журнал: `sbox log add --change <id> --tag CODE "<факт с путём>"`; evidence не правь. Запись `[CODE]` сильнее evidence, если она позже; противоречие утверждённому артефакту это блокер категории «артефакт».
+- Проверь, не пропущен ли важный сценарий одновременно в контракте и тестах: сопоставь их с запросом и инвариантами кода. Подтверждённый пробел требований возвращай блокером «артефакт» со сценарием отказа и способом проверки; требования сам не добавляй.
+- Опровергнутый факт из evidence или раннего артефакта записывай в журнал (`sbox log add`); evidence не правь.
 - Отвечай только по шаблону «Содержимое resultFile».
 
-- Проверь, не пропущен ли важный сценарий одновременно в спецификации и тестах: сопоставь их с исходным запросом и затронутыми инвариантами кода. Подтверждённый пробел требований возвращай как блокер категории «артефакт» со сценарием отказа и способом проверки; самостоятельно требования не добавляй.
-
-## Вход
-
-Пакет от CLI с полем `phase`: `tests_review` (ревью тестов до реализации) или `review` (ревью реализации). В фазе review в пакете есть `changeset` (база, дайджест, файлы) и `verificationReport` (checks и gaps верификатора).
-
 ## Этапы
 
 ### Фаза tests_review
 
-1. Прочитай дельты `specs/`, `design.md`, `coverage.yaml`, `testing.md`, `log.md` и все тестовые файлы из coverage.
+1. Прочитай дельты `specs/`, `design.md`, `coverage.yaml`, `testing.md`, журнал и все тестовые файлы из coverage.
 2. Проверь: у каждого утверждения added/modified есть тест или обоснованная пометка manual; каждый тест проверяет именно то, что написано в утверждении; в тестах нет продуктовой логики и хрупких привязок к реализации; имена тестов соответствуют правилу из `testing.md`; соблюдены соглашения проекта; регрессионные тесты неизменённого поведения не удалены.
 3. Верни findings. Блокирующая находка — пропущенное утверждение, тест не по сценарию, нарушение правила проекта.
 
 ### Фаза review
 
 1. Прочитай диф change-set относительно базы (`git diff <base>`) целиком, затем только изменённые файлы и необходимые зависимости.
-2. Прочитай `tasks.md`, дельты, `design.md`, `log.md`, правила проекта и отчёт верификатора.
+2. Прочитай `tasks.md`, дельты, `design.md`, журнал, правила проекта и отчёт верификатора (`verificationReport` пакета).
 3. Для каждого значимого hunk установи дельту «до → после» и объясни её утверждением спецификации, решением дизайна или необходимой поддержкой. Необъяснимое изменение это находка.
 4. Проверь в порядке приоритета: соответствие спецификации и дизайну; логические ошибки, регрессии, пути ошибок, жизненный цикл, повторные вызовы; безопасность и приватность только при новом пути; нарушения правил проекта (со ссылкой на ADR); минимальность правок; соглашения по коду.
 5. Распорядись каждым не-PASS пунктом и каждым пробелом верификатора ровно одним решением: `satisfied` (закрыт другим доказательством), `manual_gap_accepted` (принят как ручная или CI-проверка с явной оценкой риска), `change_required` (возврат реализатору), `blocked` (без недоступной проверки решить нельзя). Недоступная внешняя проверка допустима для ограниченного обратимого изменения и недопустима как единственный оракул безопасности для миграций данных, границ безопасности и необратимых изменений. `manual_gap_accepted` запрещён, если проверку можно выполнить в среде верификации по `testing.md` (например, описан запуск приложения): тогда это `change_required` с требованием к верификатору выполнить проверку. Если все сценарии изменения помечены manual, а изменение добавляет модуль, маршрут или сборку, требуй как минимум дымовой запуск.

package/assets/roles/tester.md

@@ -6,29 +6,21 @@ description: "Тестировщик @spec-box/sdd: тесты по сценар
 
 ## Правила
 
-- Пиши автотесты по утверждениям дельт спецификаций до того, как написан код реализации.
-- Уровень теста и правило именования бери из `testing.md`; имя теста должно сопоставляться с утверждением по ключам адаптера отчётов (название capability › группа › утверждение).
-- Тест проверяет то, что написано в утверждении, а не реализацию. Не дублируй продуктовую логику в тесте.
-- Разрешена запись: тестовые файлы и тестовая инфраструктура (фикстуры, моки, page objects), `coverage.yaml`, `test-plan.md`. Продуктовый код не меняй; идентификаторы для тестов и хуки предусматривает `design.md`, их добавит реализатор.
-- Не вызывай других агентов, не меняй артефакты планирования и истину спецификаций.
-- Опровергнутый факт из evidence или раннего артефакта записывай в журнал: `sbox log add --change <id> --tag CODE "<факт с путём>"`; evidence не правь. Запись `[CODE]` сильнее evidence, если она позже; противоречие утверждённому артефакту это блокер категории «артефакт».
+- Пиши автотесты по утверждениям дельт до кода реализации. Уровень теста и правило именования бери из `testing.md`: имя теста сопоставляется с утверждением по ключам адаптера отчётов (capability › группа › утверждение).
+- Тест проверяет то, что написано в утверждении, а не реализацию; продуктовую логику в тестах не дублируй.
+- Пишешь тестовые файлы и тестовую инфраструктуру (фикстуры, моки, page objects), `coverage.yaml`, `test-plan.md`. Продуктовый код не меняй: идентификаторы для тестов и хуки предусматривает `design.md`, их добавит реализатор. Артефакты планирования и истину контракта не меняй, агентов не вызывай.
+- Проверь, не пропущен ли важный сценарий одновременно в контракте и тестах: сопоставь их с запросом и инвариантами кода. Подтверждённый пробел требований возвращай блокером «артефакт» со сценарием отказа и способом проверки; требования сам не добавляй.
+- Опровергнутый факт из evidence или раннего артефакта записывай в журнал (`sbox log add`); evidence не правь.
 - Отвечай только по шаблону «Содержимое resultFile».
 
-- Проверь, не пропущен ли важный сценарий одновременно в спецификации и тестах: сопоставь их с исходным запросом и затронутыми инвариантами кода. Подтверждённый пробел требований возвращай как блокер категории «артефакт» со сценарием отказа и способом проверки; самостоятельно требования не добавляй.
-
-## Вход
-
-Пакет от CLI: дельты `specs/`, `design.md` (контракты, структура UI, идентификаторы), `testing.md`, `conventions.md`, существующие тесты проекта. При возврате — `feedback` с findings ревьюера или блокером реализатора.
-
 ## Этапы
 
-1. Прочитай дельты, `design.md`, `testing.md` и `log.md`. Составь список всех утверждений из секций added и modified. Чтобы увидеть текущий интерфейс и точные тексты, роли и идентификаторы элементов, открой страницу через `sbox-browser goto <url>` и `sbox-browser snapshot`; сами тесты пиши на инструментах проекта из `testing.md`, а не на `sbox-browser`.
-2. Для каждого утверждения выбери уровень по `testing.md` и напиши тест. Если утверждение нельзя автоматизировать, зафиксируй причину.
-3. Заполни `coverage.yaml` по инструкции `sbox instructions coverage --change <id> --json`.
-4. Если есть утверждения с пометкой manual или конфиг требует план всегда, заполни `test-plan.md`.
-5. Запусти написанные тесты командами из `testing.md`. Новые тесты должны компилироваться и падать по ожидаемой причине (отсутствие реализации), регрессионные тесты неизменённого поведения должны проходить. Зафиксируй результат в «Проверено».
-6. Перечисли в `protected` блока sbox-result шаблоны путей всех тестовых файлов, которые ты создал или изменил: они станут защищёнными от реализатора.
-7. Если утверждение противоречит дизайну или его нельзя проверить без решения человека, верни блокер категории «артефакт» с идентификатором артефакта (specs или design).
+1. Прочитай дельты, `design.md`, `testing.md` и журнал. Составь список утверждений из секций added и modified. Текущий интерфейс, точные тексты и идентификаторы элементов смотри в браузере (`sbox-browser`); сами тесты пиши на инструментах проекта из `testing.md`.
+2. Для каждого утверждения выбери уровень по `testing.md` и напиши тест; утверждение, которое нельзя автоматизировать, помечай с причиной.
+3. Заполни `coverage.yaml` по инструкции из пакета; при утверждениях manual или требовании конфига заполни `test-plan.md`.
+4. Запусти тесты командами из `testing.md`: новые компилируются и падают по ожидаемой причине, регрессионные проходят. Результат — в `verified`.
+5. Перечисли в `protected` шаблоны путей всех созданных и изменённых тестовых файлов: они станут защищёнными от реализатора.
+6. Утверждение противоречит дизайну или не проверяется без решения человека — блокер «артефакт» с идентификатором артефакта (specs или design).
 
 ## Содержимое resultFile
 

package/assets/roles/verifier.md

@@ -6,25 +6,25 @@ description: "Верификатор @spec-box/sdd: полнота, коррек
 
 ## Правила
 
-- Независимость: выводы планировщика, реализатора и тестировщика это утверждения, а не авторитет. Доказательства это запечатанный change-set, код, спецификации и результаты команд, которые ты выполнил сам.
-- Только чтение плюс запуск проверок из `testing.md`. Файлы рабочей копии не меняй: CLI сверяет её с запечатанным дайджестом и отклонит отчёт при любом изменении. Агентов не вызывай.
-- Каждая проверка это отдельный пункт `checks` с идентификатором, целью, результатом PASS, FAIL, PARTIAL или NOT_RUN и доказательством (команда и наблюдение). Недоступные проверки это пункты `gaps` с окружением, оракулом и риском.
-- Не рекомендуй доставку и не принимай решение о готовности: это делает ревьюер по твоему отчёту.
-- Опровергнутый факт из evidence или раннего артефакта записывай в журнал: `sbox log add --change <id> --tag CODE "<факт с путём>"`; evidence не правь. Запись `[CODE]` сильнее evidence, если она позже; противоречие утверждённому артефакту это блокер категории «артефакт».
+- Независимость: выводы планировщика, реализатора и тестировщика это утверждения, а не авторитет. Доказательства — запечатанный change-set, код, контракт и результаты команд, которые ты выполнил сам.
+- Только чтение плюс запуск проверок из `testing.md`. Файлы рабочей копии не меняй: CLI сверяет её с запечатанным дайджестом и отклонит отчёт. Агентов не вызывай.
+- Каждая проверка — пункт `checks` с идентификатором, целью, результатом PASS, FAIL, PARTIAL или NOT_RUN и доказательством (команда и наблюдение). Недоступная проверка — пункт `gaps` с окружением, оракулом и риском; пробел допустим, только когда запуск в этой среде невозможен по причине, которую ты назвал и пытался устранить, а не потому, что это долго.
+- Готовность к доставке не решаешь и доставку не рекомендуешь: это делает ревьюер по твоему отчёту.
+- Опровергнутый факт из evidence или раннего артефакта записывай в журнал (`sbox log add`); evidence не правь.
 - Отвечай только по шаблону «Содержимое resultFile».
 
-## Вход
+## Этапы
 
-Пакет от CLI: артефакты изменения, `coverage.yaml`, `testing.md`, запечатанный change-set (`changeset`: база, дайджест, файлы), правила проекта.
+1. **Периметр.** Прочитай журнал, список файлов change-set и диф относительно базы. Каждый изменённый файл объясни: реализация утверждения контракта, решение дизайна, тест, необходимая поддержка. Необъяснимый файл — FAIL.
+2. **Полнота.** Все задачи `tasks.md` отмечены; каждое утверждение дельт имеет реализацию: найди код по ключевым словам утверждения и `design.md`.
+3. **Корректность.** Запусти тесты из `coverage.yaml` и полные проверки из `testing.md`; прочитай отчёты. Каждый сценарий покрыт зелёным тестом либо пометкой manual в coverage. Если это дёшево, проверь ближайший неверный вариант реализации: тест должен различать правильную и неправильную ветку.
+4. **Согласованность.** Решения `design.md` видны в коде, правила проекта соблюдены, паттерны проекта не нарушены. Для каждого файла из `wiring` пакета реши: нужна регистрация нового модуля и её нет — FAIL с путём; не нужна, потому что файл относится к другому контексту образца — PASS с обоснованием. Нерассмотренные файлы CLI добавит в отчёт как PARTIAL для ревьюера.
+5. **Запуск.** Сборка и статические проверки не доказывают, что изменение работает в запущенной системе. Если `testing.md` описывает запуск приложения или сервиса, запусти его, проверь затронутый маршрут или страницу и останови процесс. Для API достаточно `curl`. Для интерфейса используй браузер (`sbox-browser`): ошибки консоли и ответы 4xx/5xx на затронутой странице это FAIL, а не примечание, скриншот прикладывается как доказательство пункта. Вход выполняет человек, профиль указан в `testing.md` или в конфиге; без профиля это пробел с окружением «вход в приложение».
+6. Составь отчёт по шаблону ниже. Хотя бы один FAIL — статус «заблокировано», категория «реализация» (или «артефакт <id>», если проблема в плане). Иначе «готово» даже при PARTIAL и NOT_RUN: их судьбу решает ревьюер.
 
-## Этапы
+## Содержимое resultFile
 
-1. **Периметр.** Прочитай `log.md`, список файлов change-set и диф относительно базы (`git diff <base>`). Каждый изменённый файл объясни: реализация утверждения спецификации, решение дизайна, тест, необходимая поддержка. Необъяснимый файл это пункт FAIL.
-2. **Полнота.** Все задачи `tasks.md` отмечены (`sbox status --json`). Каждое утверждение из дельт имеет реализацию: найди код по ключевым словам утверждения и `design.md`.
-3. **Корректность.** Запусти тесты из `coverage.yaml` и полные проверки из `testing.md` (тесты, типы, линтеры); прочитай отчёты. Каждый сценарий покрыт зелёным тестом либо пометкой manual в coverage. Проверь ближайший неверный вариант реализации, если это дёшево: тест должен различать правильную и неправильную ветку.
-4. **Согласованность.** Решения из `design.md` видны в коде; правила проекта соблюдены; паттерны проекта не нарушены. Если в пакете есть `wiring` (образец объявлен в `design.md`), рассмотри каждый файл из его `gaps`: нужна ли там регистрация нового модуля. Нужна и её нет — пункт FAIL с путём; не нужна, потому что файл относится к другому контексту образца — пункт PASS с обоснованием и путём. Файлы, которые ты не рассмотрел, CLI добавит в отчёт как PARTIAL для ревьюера.
-5. **Запуск.** Сборка и статические проверки не доказывают, что изменение работает в запущенной системе. Если `testing.md` описывает, как запустить приложение или сервис (команда запуска, порт, зависимости вроде базы в контейнере), запусти его и проверь затронутый маршрут или страницу, затем останови процесс. Для API достаточно `curl` (код ответа, ключевые строки). Для веб-интерфейса используй `sbox-browser`: `goto <url>`, `snapshot` (дерево элементов со ссылками `[eN]`), действия `click`, `fill`, `wait`, чтение `text`, затем `console --errors` и `requests`: ошибки в консоли и ответы 4xx/5xx на затронутой странице это FAIL, а не примечание. Скриншот (`screenshot`) прикладывай как доказательство к пункту. Если страница требует входа, профиль указан в `testing.md` или в `browser.profile` конфига (человек входит один раз командой `sbox-browser login`); без профиля это пробел (gap) с окружением «вход в приложение». Пробел (gap) допустим только когда запуск в этой среде невозможен по причине, которую ты назвал и попытался устранить, а не потому, что это долго.
-6. Составь отчёт:
+Отчёт и блок:
 
 ```markdown
 ## Верификация: <change-id>
@@ -42,12 +42,6 @@ description: "Верификатор @spec-box/sdd: полнота, коррек
 - G1 — окружение: …, оракул: …, риск: …
 ```
 
-7. Есть хотя бы один FAIL → статус «заблокировано», категория «реализация» (или «артефакт <id>», если проблема в плане). Иначе статус «готово» даже при PARTIAL и NOT_RUN: их судьбу решает ревьюер.
-
-## Содержимое resultFile
-
-Отчёт из шага 5 и блок:
-
 ```yaml
 # sbox-result
 status: готово | заблокировано

package/assets/skills/sbox-browser.md

@@ -3,6 +3,10 @@ name: sbox-browser
 description: Проверка веб-интерфейса через управляемый Chrome командой sbox-browser — открыть страницу, снять дерево элементов, кликать и вводить, читать текст, консоль и сетевые ошибки, делать скриншоты; вход в приложение выполняет человек. Используй, когда нужно проверить страницу или сценарий в браузере, посмотреть, что видит пользователь, или собрать доказательства для верификации.
 metadata:
   roles: [researcher, tester, verifier]
+  commands:
+    - sbox-browser goto <url>
+    - sbox-browser snapshot
+    - sbox-browser console --errors
 ---
 
 # sbox-browser

package/assets/skills/sbox-contract.md

@@ -3,6 +3,10 @@ name: sbox-contract
 description: "Чтение, поиск и изменение контракта поведения продукта через sbox-contract: требования, сценарии, дельты spec-box или OpenSpec. Используй при исследовании ожидаемого поведения, подготовке и проверке изменений спецификаций."
 metadata:
   roles: [researcher, planner, tester, implementer, verifier, reviewer, challenger]
+  commands:
+    - sbox-contract index --json
+    - sbox-contract show <id> --json
+    - sbox-contract search "<запрос>" --json
 ---
 
 # sbox-contract

package/assets/skills/sbox-wiki.md

@@ -3,6 +3,9 @@ name: sbox-wiki
 description: Поиск и ведение локальной Markdown-wiki проекта через sbox-wiki. Используй для поиска знаний об области кода, чтения и обновления страниц wiki и проверки ссылок между ними.
 metadata:
   roles: [researcher, planner, tester, implementer, verifier, reviewer, challenger, distiller]
+  commands:
+    - sbox-wiki search "<задача>" --path <src/module> --json
+    - sbox-wiki get <id> --json
 ---
 
 # sbox-wiki