fix

Prompt file imported from Keksov/MindWaveCore (.claude/commands/fix.md). Fill in {{arguments}} before use. Copyright stays with the author.

Ты исполняешь фичу по методу Plan+Ledger (сам метод — в правилах рабочего пространства, здесь только маршрутизация и дисциплина). Аргумент: {{arguments}} — имя фичи (папка MindWaveCore/docs/<фича>/) или id находки F-xxxx.

Маршрутизация

• Дан F-xxxx → путь к фиче лежит в поле plan этой находки в MindWaveCore/docs/qa/findings.json. Поле пустое → стоп: сначала /qa plan <F-id>.
• Авторитетные файлы: <фича>-plan.md (требования владельца и решения XX-Dn) и <фича>-progress.json (леджер). Прочитай план ЦЕЛИКОМ до первого шага — решения связывают.

Дисциплина исполнения

1. Перечитай план и леджер с HEAD в начале работы и снова перед КАЖДОЙ записью в леджер — параллельные сессии могли его подвинуть (git show HEAD:<путь> при сомнении). Одна сессия на леджер одновременно: если видишь чужой свежий active-шаг — стоп, спроси владельца.
2. Возьми первый pending-шаг, у которого все dependsOn в done. Переведи в active и работай.
3. verify шага прогоняй ДО перевода в done, и в evidence пиши не «тесты зелёные», а что именно измерено: числа, состав прогонов, приложенный вывод. Красный verify — шаг не done.
4. При записи в леджер обновляй поле status и даты, а не только текст рядом с verify (известная ловушка: правка по якорю verify оставляет status протухшим). Перед каждым коммитом, трогающим docs/, из корня KKMindWave: MindWaveCore/server/bun.exe run validate-ledger.js MindWaveCore/docs/<фича>/<фича>-progress.json; если правились файлы docs/qa/ — ещё и validate-qa.js MindWaveCore/docs/qa.
5. Коммит на шаг атомарный, с префиксом id шага; стадишь только свои файлы, чужой репозиторий — через git -C <repo>.
6. PAUSE-шаг — полный стоп. Доложи владельцу простыми словами, что сделано и какое решение за ним, и жди. blocked — то же: статус, причина в blockedReason, доклад, стоп.
7. Все шаги done → доложи итог. Если фича родилась из находки (в плане есть F-id), закрытие находки — через /qa close <F-id>: регрессионный замок в реестр там, не здесь.

Наследуемые правила безопасности

• Прогоны uitest — только в песочнице (HK_WRITE_FENCE, GCY-D38); раннер — node, не bun.
• Не больше двух прогонов одновременно; пересборка UI трогает общий server/public — её не запускать параллельно ни с чем.
• Перед прогоном сценариев пересобери UI: песочница отдаёт server/public, иначе проверяешь вчерашний код.
• В чате объясняй сначала простыми словами, жаргон и ссылки на код — после.