openspec-explore

name: openspec-explore description: Единая точка входа — исследование задачи, дефекта или вопроса. Финал bug-профиля — блок «## Постановка ЗНИ» в чате; question — свод «Итог / Вердикт / Дальше»; фича — redirect на /opsx:new license: MIT compatibility: Requires openspec CLI. metadata: author: openspec version: "3.0"

/opsx:explore — единая точка входа (Ultra-Lite)

Любой свободный текст пользователя (без другой команды) = вход в explore.

Ценность: заказчик получает решение в чате — Итог / Вердикт / Дальше после каждого шага и финальный блок ## Постановка ЗНИ (bug-профиль). Chat Surface Contract §2.6: бриф и финал — типографика Правила 4 (первая строка — суть, ≤25 слов, без таблиц в чате).

Не делает: правки BSL, создание openspec/changes/ целиком, полный набор артефактов ЗНИ без /opsx:new. Не создаёт каталог openspec/sessions/ — он удалён как обязательный артефакт.

Bootstrap (первый ход новой темы)

Одна строка в чат:

«Готов разобрать задачу, дефект или вопрос. Опишите, с чем работаем — выдам короткий бриф и согласуем маршрут.»

Не делать: автоматический матчинг по токенам запроса, Read temp/reports/*.md до ответа пользователя, перебор legacy openspec/sessions/. Список команд не показывать (только если пользователь явно попросит перечень команд).

Continuity (когда пользователь просит продолжить)

Если в первом сообщении пользователь пишет «продолжи разбор …», «вернёмся ко вчерашнему», «по той же теме что и …»:

1. Glob temp/reports/*.md — отчёты за последние 7 дней.
2. Фильтр по теме (имя файла + первая строка/заголовок).
3. Если найдено 1–3 — короткая строка в чат: «Нашёл следы по теме: <пути>. Продолжаем с этого момента?»; пользователь подтверждает текстом.
4. Если не найдено — обычный вход (новый якорь и план).

Запрещено: bootstrap openspec/sessions/, Read brief.md старых сессий, авто-резюм без текстового подтверждения. Legacy openspec/sessions/* читается только по явной ссылке пользователя в чате — как обычный файл, без активации старого протокола.

Entry Protocol (MANDATORY)

До утверждения брифа запрещено: Task, TodoWrite, Read .bsl/трассы/модулей, Grep по src/.

Допустимо до брифа: Read этого SKILL, openspec/project.md, KB Discovery (openspec/knowledge/_index.yaml), Glob по именам из постановки (1–3 вызова), openspec list --json, AskQuestion только для §2 (неоднозначная именная сверка) — не для утверждения плана.

0. Активные ЗНИ (контекст, не redirect)

openspec list --json. Если есть change в той же области: строка «Контекст ЗНИ: <name>» добавляется в бриф только если ЗНИ блокирует продолжение или название ЗНИ явно упомянуто пользователем. Иначе результат openspec list — это non-event, в чат не выводится. Capture fix — после ответа: /opsx:extend <change> --from-report <path>.

0.5. Readiness Check (лёгкий, только для сырой постановки)

Если вход слишком сырой для брифа — нет ни симптома/цели, ни намёка на область (например «почини отчёт», «что-то с проведением», «сделай нормально») — не выдумывать слоты брифа B3. Вместо этого один короткий вопрос в чат (текстом, не AskQuestion), закрывающий минимум для брифа:

• что именно наблюдается / какой результат нужен (1 фраза);
• где примерно (документ, отчёт, обработка, подсистема) — если знает.

Один проход. Получив ответ — обычный бриф (§3). Если вход уже содержит симптом и область — Readiness Check пропускается (это non-event, в чат не выводится). Не превращать в анкету: максимум один уточняющий вопрос до брифа.

1. Профиль

Маркеры постановки фичи («нужно сделать», «добавить», «изменить поведение») → перенаправить на /opsx:new. Если непонятно, что трогать — короткая разведка через explore-question (1–2 Task к explorer). Профиль пользователю не называть.

Смешанный вход с дефектом → explore-bug.

1.6. Knowledge Discovery (internal)

По architect-gate.mdc / 1c-agent-delegation.mdc §KB CONTEXT. KB не в чат-бриф; полный список — в промпты агентов после «да».

2. Именная сверка (лёгкая)

1–3× Glob/Grep только по именам из постановки. Не читать .bsl. Не найдено / неоднозначно → один AskQuestion → снова сверка → бриф.

Verify-or-hypothesis: без сверки — только в Гипотезы, не в Факты.

3. Бриф B3 в чате (END TURN)

SSOT формы: .cursor/docs/templates/brief-card.md (классификатор — opsx-output-style.md §5.1). Уровень B3 — только для explore.

Заголовок: Бриф: <тема>.

Форма — карточка слотов (бюджет содержания: ≤6 заполненных слотов, скан ~30 сек):

• Маршрут — один абзац: как разберём (без имён агентов).
• Варианты — нумерованный список 2–3 альтернатив «куда копать сначала»; в Подтвердить? — номер или «да» (= вариант 1).
• Слот План не используется.

Запрещено: Что понял, Бриф для исследования; второй заголовок брифа; имена агентов; target/prev; KB / openspec list в чате; только AskQuestion без полного текста брифа (HALT).

После брифа в чате — END TURN. Без Task/TodoWrite.

HALT перед отправкой: если есть AskQuestion для утверждения плана, или нет обязательных слотов (Симптом, Маршрут или Варианты, Вопрос, Подтвердить?), или Маршрут и Варианты одновременно — переписать ответ.

После «да» (цикл исследования)

После текстового подтверждения пользователя — никаких файлов состояния (brief.md, todo.md, step-*.md). Якорь «Решено, когда» живёт в сообщениях чата; при уточнении — пересогласуй вслух.

Implementation Intent HALT (после выбора решения — не правка кода)

Срабатывает, если пользователь уточняет как реализовать (не только «что понять»):

• Маркеры: «нужно B», «мягкий отказ», «сделай», «реализуй», «добавь в код», выбор варианта A/B/C как решение для ЗНИ.
• Запрещено: Write/StrReplace по src/** (в т.ч. .bsl в cfe/**), вызов onec-code-writer, создание openspec/changes/<name>/ целиком без команды /opsx:new.
• Действие: обновить или дополнить блок ## Постановка ЗНИ в чате → предложить /opsx:new <kebab-name> (имя derive из темы исследования, 2–4 значимых слова).

Pre-flight перед любым изменением файла в explore-сессии (оркестратор, мысленно; при срабатывании — HALT):

1. Активная команда = /opsx:explore?
2. Путь под src/**/cfe/** и расширение .bsl (или иной код реализации)?
3. В сессии уже был /opsx:apply?
4. Если (1) и (2) да, а (3) нет → HALT, не вызывать Write/StrReplace; только артефакты в чате и redirect на new/apply.

Архивный контекст (предохранитель от ложной причины)

Срабатывает при любом из:

• пользователь явно сослался на ЗНИ / архив / отчёт (@openspec/changes/..., имя change в тексте);
• в брифе указаны пути/имена из openspec/changes/archive/** или активного change;
• openspec list --json показывает активный change в той же области.

Действие (оркестратор, до первого Task или сразу после trace, если ссылка появилась позже):

1. Glob openspec/changes/archive/**/proposal.md и при необходимости активных openspec/changes/<name>/proposal.md — не более 10 каталогов; при пересечении с постановкой — Read proposal.md (§Why), debug.md, reports/exploration-*.md, reports/architecture-*.md.
2. Классифицировать связь с симптомом одной меткой на источник:
   • directly-related — тот же сценарий + та же область + симптом совпадает или покрыт → открытые гипотезы (## Hypotheses без confirmed/refuted, inconclusive в exploration) поднимаются как кандидаты причины; передать в open_hypotheses_from_archive[] в промпт trace-analyst/explorer.
   • adjacent — смежная область, симптом другой → только в превью как «попутно», не ставить причиной.
   • unrelated — формальное пересечение по словам, симптом не покрыт → одна строка в финальном блоке: «архив <name> проверен, не объясняет».
3. Для bug-профиля, если этот шаг сработал, классификация обязательна в финальном блоке ## Постановка ЗНИ (поле «Связь с архивом»).

HALT-правило: пользовательская ссылка на ЗНИ/архив не делает этот архив автоматически причиной. Сначала Symptom Relevance Check, затем классификация.

Маршрут шагов

Один из трёх типов (можно комбинировать в пределах лимита):

Промпт Task обязан содержать:

• user-goal и «Решено, когда» из брифа в чате.
• Пути cf/cfe из openspec/project.md.
• open_hypotheses_from_archive[], если § «Архивный контекст» сработал.
• Блок ## Existing Knowledge (если KB Discovery дал совпадения).
• Требование сохранить полный отчёт в temp/reports/<тип>-YYYY-MM-DD-<slug>.md.
• Для bug — раздел ## Для заказчика в отчёте (см. profiles/bug.md).

Жёсткие лимиты

• ≤ 3 Task (trace + explorer) на одну тему без явного «копаем глубже» от пользователя.
• Architect — вне лимита 3. Если триггеры architect-gate.mdc сработали, Task к onec-code-architect запускается дополнительно; отчёт в temp/reports/architecture-YYYY-MM-DD-<slug>.md; флаг «architect: yes» — в финальном блоке.
• END TURN только при реальной развилке (≥ 2 взаимоисключающих пути), не после каждого шага.
• Полный отчёт каждого Task — обязательно в temp/reports/ (см. preserve-subagent-reports.mdc); превью в чат не отменяет Write полного отчёта.

Вывод в чат (после каждого Task)

В чат — обязательно, в одном сообщении:

1. Превью отчёта (8–15 строк)

Сразу после Task: краткий пересказ простым языком + путь к полному отчёту в temp/reports/.... Якоря (модуль:строка, #событие трассы) живут в отчёте; в чат — максимум 1 имя как анкор «где смотреть». Без полного дублирования отчёта.

1.5. Symptom Relevance Check (для bug-профиля)

До формирования синтеза:

• Что хочет устранить пользователь? → слот Вопрос из брифа в чате (= user-goal).
• Что нашли в отчёте? → секции ## Для заказчика / ## Свод.
• Объясняет ли найденное симптом? → объясняет | частично | не объясняет (internal; в чат — UX-фраза «найденное объясняет симптом: да / частично / нет»).
• Если не объясняет или частично:
  • проверить § «Архивный контекст»;
  • в Вердикт синтеза запрещено «штатно» / «допустимое поведение» / «норма» как итог по симптому пользователя — обязан назвать другую причину (из архива или следующий шаг) или «причина не найдена, нужен шаг X».

2. Синтез — Итог / Вердикт / Дальше

**Итог** — 2–4 буллета с доказательствами простым языком (детальные якоря — в отчёте).

**Вердикт** — одна фраза: баг | штатно (с оговоркой UX) | нужна правка | не хватает данных.

**Дальше** — ровно одно: действие в Конфигураторе | `/opsx:new` / `/opsx:extend` | один вопрос | «достаточно».

HALT: только путь к файлу без «Итог / Вердикт / Дальше»; бинарный «достаточно? да/нет» без конкретного «Дальше».

3. Развилка (опционально)

Если есть ≥ 2 взаимоисключающих пути — компактная карточка вариантов в пределах «Дальше», затем END TURN до ответа пользователя обычным текстом.

Интерпретация ответа пользователя:

Финал bug-профиля: блок ## Постановка ЗНИ в чате

Когда якорь Вопрос / user-goal снят и причина названа — последний блок в чате (не файл).

Каркас и правила сборки — единственный источник: templates/handoff-block.md. Каждое поле — выжимка из конкретных отчётов Task (temp/reports/*) и решений чата, не копия слотов брифа и не placeholder-текст.

Композиция финального сообщения (HALT):

• Блок заменяет синтез «Итог / Вердикт / Дальше» — не печатать оба в одном сообщении.
• Один «Следующий шаг» на сообщение: /opsx:new <name>. Вторых строк «Дальше:» с другими действиями быть не должно.
• Содержание полей не дублируется буллетами выше по сообщению.

Блокирующая развилка (гибрид): если осталось решение заказчика, меняющее «Что менять» или «Приёмку» (выбор A/B), — блок не печатается: сначала компактная карточка решения, END TURN; после ответа блок собирается с уже вшитым решением. Неблокирующие вопросы — в поле «Открытые решения» (команда new перенесёт их в design.md § Открытые вопросы).

Symptom Lock: запрет финального вердикта «штатно / не чинить», пока якорь не снят или явно не пересогласован в чате. Маркеры причины ([verified] / [hypothesis: план]) — обязательны; hypothesis без плана запрещена. Запрещены однострочные пункты-телеграммы для Симптома, Причины и Что менять.

/opsx:new и /opsx:extend подхватывают этот блок прямо из чата (приоритет 1). Handoff-файл — резерв (см. ниже).

Опциональный handoff в файл (только по словесной просьбе)

Триггеры: пользователь в чате говорит «сохрани», «зафиксируй в файл», «нужен handoff», «передай команде», «вынеси в файл».

Действие: Write temp/explore-handoff-YYYY-MM-DD-<slug>.md — один плоский файл:

# Handoff: <тема>
**Дата:** YYYY-MM-DD
**Источники:** temp/reports/<тип>-YYYY-MM-DD-<slug>.md, …

## Постановка ЗНИ
(тот же блок, что выше)

## Доказательства
- модуль:строка
- #событие трассы
- ссылка на архивный change

По умолчанию не создаётся. Без словесной просьбы explore завершается блоком в чате.

Per-turn Delegation Gate

После утверждения брифа: обследование кода → только Task (onec-code-explorer, onec-trace-analyst, onec-code-architect). Оркестратор не читает .bsl для анализа. До 3 Read артефактов OpenSpec для подготовки брифа или промпта Task — допустимо.

Бриф для трассы готовится здесь (из пользовательского ввода и брифа в чате), не в отдельном файле.

Change Creation Gate

«Создай ЗНИ» / полный набор артефактов → СТОП. Финальный блок ## Постановка ЗНИ в чате, затем предложить вилку, а не молча выбирать один путь:

• новый change — /opsx:new <name> (все артефакты разом, задача понятна);
• дополнить существующий change — /opsx:extend <change> (требование ложится в уже идущую ЗНИ).

Не Write proposal.md / design.md / tasks.md вручную.

Новое требование в существующий change → /opsx:extend. Точечный capture в design — только по явной просьбе.

Architect Gate / Verified Cause

Триггеры — .cursor/rules/architect-gate.mdc, .cursor/rules/verified-cause-gate.mdc. При срабатывании — Task → onec-code-architect (модель по .cursor/rules/model-selection.mdc). Отчёт — temp/reports/architecture-YYYY-MM-DD-<slug>.md. В финальном блоке — поле «Architect / verify: да».

Capture (по запросу)

«Зафиксируй в проекте» → .cursor/rules/capture-to-project.mdc. Решение в существующий change → /opsx:extend.

Handoff в ЗНИ

/opsx:new опускает entry-бриф, если в чате есть свежий блок ## Постановка ЗНИ (B0: одна информирующая строка, имя не согласовывается).

Guardrails

• BSL write guard, tool-name-guard, 1c-agent-delegation — без исключений.
• preserve-subagent-reports.mdc — полный отчёт каждого аналитического Task в temp/reports/; превью в чат это не заменяет.
• Explore не реализует код; /opsx:apply — отдельная команда.
• Bootstrap openspec/sessions/ запрещён; чтение legacy — только по явной ссылке пользователя.

Self-check брифа (перед END TURN)

1. Тело брифа B3 напечатано в ответе; форма по brief-card.md?
2. Обязательные слоты: Симптом, Маршрут или Варианты (не оба), Вопрос, Подтвердить?; ≤6 заполненных слотов?
3. Нет запрещённых подписей (Что понял, Как буду искать и т.д.)?
4. Нет AskQuestion для утверждения плана (допустим только §2)?
5. Нет жаргона движка в UX-полях (.cursor/docs/opsx-output-style.md §3.1)?
6. В чате нет имён агентов, target/prev, статусов служебных проверок?
7. Один бриф, без дубля?
8. Нет Task/TodoWrite до ответа «да»?

Self-check хода (после каждого Task)

1. В чате есть превью 8–15 строк с путём к temp/reports/...?
2. Для bug — Symptom Relevance Check выполнен до «Вердикта»?
3. Есть блок «Итог / Вердикт / Дальше»? «Дальше» — конкретный шаг, не бинарное «да/нет»?
4. Лимит ≤ 3 Task соблюдён (architect — отдельно)?
5. Полный отчёт Task сохранён в temp/reports/?

Self-check финала bug

1. Якорь Вопрос / user-goal снят (или прямо пересогласован)?
2. Блок ## Постановка ЗНИ напечатан в чате (не только в handoff-файле)?
3. Маркер причины: [verified] или [hypothesis: план]?
4. Связь с архивом классифицирована, если §«Архивный контекст» сработал?
5. Handoff-файл создан только если пользователь словами попросил?
6. В сообщении один «Следующий шаг» и нет синтеза «Итог / Вердикт / Дальше» рядом с блоком (композиция — templates/handoff-block.md)?
7. Блокирующих развилок в полях блока нет (решения вшиты или вынесены в карточку до блока)?