Пошаговая реализация кода по утверждённому ТЗ — один тонкий вертикальный срез за раз, «читай перед правкой», маленькие проверяемые шаги, коммит как точка сохранения, безопасные значения по умолчанию. Применяйте для «напиши код», «реализуй фичу», «добавь / измени / отрефактори», «собери проект», «допиши функцию». Не подходит для сбора требований и архитектуры (dev-spec), тестирования и отладки (dev-test), ведения проекта и памяти (dev-project) — или если ещё нет ТЗ.

Разработка: реализация по ТЗ

Писать код по утверждённому ТЗ (SPEC.md), маленькими проверяемыми срезами. Цель — не выдать кусок кода, а продвинуть проект так, чтобы его можно было проверить и откатить. Каждая правка оставляет проект в рабочем состоянии.

Когда активирован

• Есть согласованное ТЗ (или компактный его вариант), и пора писать код.
• Просьбы «напиши / реализуй / добавь / измени / отрефактори / собери».
• Продолжение работы по чек-листу задач из SPEC.md.

Не активируй для сбора требований (dev-spec), тестов/отладки (dev-test) или если ТЗ ещё не согласовано. Если ТЗ нет — сначала dev-spec.

Главный принцип: тонкие срезы + читай перед правкой

Тонкий вертикальный срез = один путь пользователя от начала до конца, на самом простом уровне. Сначала делаем так, чтобы весь путь заработал кое-как, потом добавляем толщину (надёжность, ошибки, красоту). Не писать три дня «фундамент», после которого ничего не запускается.

Читайте перед правкой: никогда не правь файл, который не прочитал. Сначала read целевой файл и его соседей — пойми контекст, имена, стиль. Дублирование существующей функции или конфликт имён — обычный результат «правки вслепую».

Процесс (один срез = один цикл)

1. Выбери одну задачу из чек-листа (самую левую/базовую). Не три за раз.
2. Прочитай файлы, которые затронешь, и те, на которые опираешься.
3. Спланируй изменение коротко (1–3 предложения: что меняю, зачем, как проверю).
4. Реализуй минимально. Без «на всякий случай», без преждевременной абстракции.
5. Запусти — приложение или тест (см. dev-test). Убедись, что стало работать.
6. Зафиксируй — коммит/сохранение как точку отката; запиши шаг в журнал (dev-project).
7. Повтори для следующей задачи.

После каждого среза проект должен запускаться и делать на одну вещь больше, чем до.

Кросс-платформа: не предполагай bash/python

Это критично. Пользователь запускает код у себя — а у него может быть Windows, где:

• Node есть всегда (вшит в десктоп AgentHere и часто установлен отдельно).
• Python может отсутствовать, как и Unix-утилиты (grep, cat, curl, bash).
• Оболочка — PowerShell/cmd, не bash.

Правила:

• Если пишешь вспомогательный скрипт для самого агента/сборки — используй Node (.js/.mjs), не bash и не python. Node работает на всех платформах.
• Команды запуска давай на языке проекта (npm/bun, pip, cargo…) и предупреди, если команда может не сработать на Windows — предложи аналог (PowerShell).
• В package.json/pyproject.toml клади команды запуска — тогда npm run X / python -m X единообразно работает везде.
• Не используй bash-специфику (&&, heredoc, $VAR) в инструкциях пользователю — давай по одной команде или скрипт-обёртку.
• Для путей — / работает на всех ОС; не вшивай \\.

Стиль и гигиена

• Соответствуй окружающему коду. В существующем проекте — копируй его стиль, имена, отступы. Не навязывай «свой» стиль.
• DRY, но без фанатизма. Дублирование двух строк лучше преждевременной абстракции. Правило трёх: выноси в общее, когда повторилось трижды с вариацией.
• Безопасные значения по умолчанию: честные ошибки лучше тихихfallback'ов; fail-closed (лучше упасть явно, чем вернуть пустоту, которую никто не заметит).
• Имена говорят «что», не «как». fetch_prices() лучше do_stuff().
• Один срез — одно логическое изменение. Не миксуй «добавил фичу» и «рефактор» в одной правке — обе правки тяжело ревьюить и откатывать.

Границы (✅ / ⚠️ / 🚫)

• ✅ Всегда: читать перед правкой; запускать после каждого среза; коммитить после зелёного; следовать стилю проекта; писать кросс-платформенные команды.
• ⚠️ Спросить: добавлять новую зависимость; менять схему БД; трогать конфиг/CI; удалять или переписывать большой кусок чужого кода; править то, что помечено «не трогать» в SPEC.md.
• 🚫 Никогда: не коммитить секреты/ключи/токены; не править node_modules/, .venv/, vendor/, сгенерированное; не удалять падающий тест, чтобы «зеленело»; не оставлять проект в нерабочем состоянии после среза.

Отговорки и почему они не работают

Выходные критерии (проверь перед завершением среза)

• Срез делает на одну вещь больше, и проект запускается.
• Прочитал все затронутые файлы перед правкой.
• Команды запуска кросс-платформенны (Node, а не bash-специфика).
• Нет секретов в коде; не тронуты node_modules//.venv//сгенерированное.
• Шаг записан в журнал проекта (dev-project); коммит как точка отката.

Дальше: проверить — навык dev-test. Вести статус и память — dev-project.