Редактирование и итерации изменений

Каждый артефакт изменения — это просто файл Markdown, который вы можете редактировать в любое время. Нет заблокированной «плановой фазы», нет шлюза утверждения, нет специального режима редактирования. Хотите изменить предложение после того, как начали разработку? Откройте proposal.md и измените его. Осознали, что дизайн неверен во время реализации? Исправьте design.md и продолжайте работу. Это весь ответ, и это сделано намеренно.

Эта страница предназначена для момента, когда вы думаете: «подождите, могу ли я вернуться и изменить это?» Да. Вот как это сделать в каждом распространенном случае.

Два способа редактирования чего угодно

У вас всегда есть оба варианта:

1. Отредактируйте файл напрямую. Артефакты — это обычный Markdown-код в openspec/changes/<name>/. Откройте proposal.md, design.md, tasks.md или спецификацию дельты в specs/ в вашем редакторе и измените их. Ничего другого не требуется.

2. Попросите ИИ пересмотреть его. В чате просто скажите, что вы хотите: «Обновите предложение, чтобы исключить идею кэширования и добавить раздел о лимитах запросов» или «дизайн должен использовать очередь, а не опросы (polling)». ИИ редактирует артефакт для вас, используя остальную часть изменения в качестве контекста.

Используйте тот, который подходит моменту. Небольшая формулировка? Отредактируйте файл. Существенное переосмысление? Пусть ИИ проведет ревизию с полным контекстом.

«Как мне обновить предложение (или спецификации) после того, как я начал?»

Просто обновите. То же изменение, но в улучшенном виде.

Если вы используете расширенные команды, естественный порядок действий таков: отредактируйте артефакт, а затем выполните /opsx:continue, чтобы продолжить работу с нового состояния, или /opsx:apply, чтобы продолжать реализацию на основе обновленного плана. Если вы используете стандартные команды core, отредактируйте артефакт и выполните /opsx:apply; он читает текущие файлы, поэтому он строит код на основе того, что написано в артефактах.

Ментальная модель: артефакты — это живой план, а не подписанный контракт. ИИ всегда работает с их текущим содержимым, поэтому редактирование этих файлов направляет работу.

Вы: Я хочу изменить подход в этом изменении.

Вы: [отредактируйте design.md или скажите ИИ:]
     Обновите design.md, чтобы использовать фоновую задачу вместо синхронного вызова.

ИИ:  design.md обновлен. Список задач все еще подходит; хотите ли вы, чтобы я продолжил применение?

Вы: /opsx:apply

Это ответ на очень частый вопрос: нет отдельной команды «обновить предложение», потому что она не нужна. Файл является источником истины, и его редактирование (вручную или через ИИ) — это обновление.

«Как мне вернуться к просмотру после реализации?»

Вам не нужно «возвращаться», потому что вы никогда не уходили. Рабочий процесс гибок: просмотр, редактирование и реализация — это не последовательные фазы, в которые вы застряли.

Конкретно, после некоторой работы /opsx:apply:

• Хотите ли вы пересмотреть план? Откройте артефакты и прочитайте их или выполните openspec show <change> в терминале для консолидированного просмотра.
• Нашли что-то, что нужно изменить? Отредактируйте артефакт (или попросите ИИ), а затем продолжайте работу.
• Хотите структурированную проверку того, соответствует ли код плану? Выполните /opsx:verify (расширенная команда). Он сообщает о полноте, корректности и связности без блокировки чего-либо. См. Workflows: Verify.

Нет «фазы просмотра», к которой можно было бы вернуться, потому что просмотр — это то, что вы можете делать в любой момент, включая после реализации.

«Я отредактировал код вручную. Как мне согласовать это с OpenSpec?»

Это происходит постоянно, и это нормально. Вы внесли изменения в своем редакторе, и теперь код и артефакты расходятся. Верните их в синхронизацию в любом направлении:

• Код теперь корректен, а спецификация устарела. Обновите спецификацию дельты (и задачи, если это применимо), чтобы описать поведение, которое вы фактически выпустили. Спецификация должна соответствовать реальности до архивирования, поскольку архивирование объединяет спецификацию с вашим источником истины.
• Спецификация корректна, а код отклонился. Продолжайте работу или исправляйте, пока код не совпадет со спецификацией.

Быстрый способ выявить несоответствия — это /opsx:verify: он читает ваши артефакты и ваш код и говорит вам, где они расходятся. Относитесь к его выводу как к списку задач для согласования, а затем архивируйте, когда они согласуются.

Принцип таков: на момент архивация ваши спецификации становятся истиной записи. Поэтому перед архивированием сделайте так, чтобы спецификации честно отражали то, что делает код. Ручное редактирование приветствуется; просто не позволяйте ему незаметно рассинхронизировать спецификацию.

Улучшение предложения, которое вас не устраивает

Если сгенерированное предложение не соответствует ожиданиям, у вас есть три хороших варианта:

• Итерируйте на месте. Скажите ИИ, что не так («область слишком широка, исключите функции администратора»), и позвольте ему пересмотреть. Это самый дешевый и обычно правильный вариант.
• Сначала исследуйте, а затем заново предлагайте. Если проблема в том, что сама идея неясна, вернитесь к /opsx:explore, обдумайте это и дайте более четкое предложение. См. Explore First.
• Начните с нуля. Если намерение изменилось фундаментально, новое изменение может быть яснее, чем исправление старого.

Этот последний вариант имеет собственное руководство по принятию решений, далее.

Когда обновлять, а когда начинать новое изменение

Коротко: обновляйте, если это та же работа в улучшенном виде; начинайте новую, если намерение изменилось фундаментально или область работы разрослась до других задач.

• Та же цель, но лучший подход? Обновите.
• Сужение области (выпустить MVP сейчас, остальное позже)? Обновите, затем заархивируйте, а потом создайте новое изменение для фазы два.
• Сама проблема изменилась («добавить темную тему» превратилось в «построить полноценную систему тем») ? Новое изменение.

Полная блок-схема и примеры работы приведены в Workflows: When to Update vs Start Fresh, а более глубокое рассмотрение — в OPSX: When to Update vs. Start Fresh.

Примечание о задачах

tasks.md — это живой контрольный список, а не замороженный план. По мере реализации вы можете добавлять обнаруженные задачи, удалять те, которые оказались ненужными, или менять их порядок. ИИ отмечает пункты в процессе выполнения /opsx:apply, и он возобновляется с первой непомеченной задачей, если вы вернетесь позже. Редактирование списка в процессе работы ожидаемо.

Куда двигаться дальше

• Workflows — шаблоны, а также руководство по принятию решения (обновить vs. новое)
• Explore First — место, куда можно вернуться, когда идея нуждается в переосмыслении
• Commands — /opsx:continue, /opsx:apply и /opsx:verify подробно
• Concepts: Artifacts — для чего нужен каждый артефакт