Как исправить баг по issue и открыть PR с Искрой

Передайте агенту воспроизводимую ошибку и границы изменений. Искра может пройти связную задачу: прочитать issue и код, предложить тест, подготовить исправление и при подключённом GitHub открыть PR через согласованные операции записи.

Что получить для ревью

• Минимальный diff и тест, объясняющий исправленное поведение.
• Отчёт: что запускали, с каким результатом и что осталось непроверенным.
• PR в выбранную базовую ветку после согласования или patch и файлы для ручного переноса.

Учебный issue: потерян последний день периода

В выгрузке оплаченных заказов за 30-31 октября пропали заказы за 31-е число. Причина в сравнении верхней границы: использовано < вместо <=. Даты в примере календарные, без времени и часовых поясов.

Скачать модуль, данные, тесты и эталон ZIP. В архиве отдельно лежат исходная версия и исправленный эталон. Начните с example-input, не подменяя его готовым ответом.

Как пройти от issue до проверяемого PR

1. Ограничьте задачу одним issue. Дайте номер issue, repo, базовую ветку, ожидаемый результат и список допустимых файлов. Для закрытого проекта сначала проверьте, что код разрешено передавать в выбранный рабочий контекст.
2. Выберите способ доступа. Для работы через GitHub нужен доступный навык, подключение и права к нужному репозиторию. Проверьте их в «Навыках». Без подключения приложите issue, нужные файлы и тесты: Искра сможет подготовить patch для ручного переноса.
3. Попросите найти причину и воспроизведение. Агент читает issue и код, выделяет минимальный участок и готовит тест по критериям приёмки. Тест считается выполненным только при наличии реального запуска и результата; чтение кода этого не заменяет.
4. Получите и проверьте минимальное исправление. Сначала посмотрите diff. Тесты можно запускать лишь в доступной совместимой среде. В песочнице нет произвольного сетевого доступа: загрузку любых зависимостей, клонирование проекта и полноценную IDE обещать нельзя.
5. Согласуйте запись и открытие PR. Подключённый GitHub предлагает отдельные формы подтверждения для операций записи. Проверьте создание ветки, запись файлов/коммита и параметры PR. Открытие PR и слияние являются разными действиями.
6. Прочитайте фактический статус проверки. Попросите ссылку на PR, перечень файлов и отчёт о выполненных тестах. Агент может прочитать доступные статусы и логи CI. Если проверка ожидает или недоступна, итог остаётся неизвестным до её завершения.

Полный промпт для исправления ошибки

Укажите реальные границы задачи. В файловом варианте замените параметры репозитория на список приложенных файлов и попросите остановиться после подготовки patch.

Разбери issue и подготовь минимальное исправление.

Репозиторий: [владелец/репозиторий]. Issue: [номер или приложенный issue.md].
Базовая ветка: [ветка]. Разрешённая новая ветка: [имя].
Разрешённые файлы/модули: [перечень]. Критерии приёмки: [ожидаемое поведение].
Команда проверки: [команда проекта, для учебного примера python3 -m unittest -v].

1. Прочитай issue, обсуждение и связанные файлы. Зафиксируй исходную ревизию. Если данных или прав недостаточно, сообщи, чего не хватает.
2. Объясни причину и предложи минимальное изменение без постороннего рефакторинга и зависимостей.
3. Подготовь тест, который воспроизводит ошибку и проверяет границы. Прежде чем заявить о воспроизведении, запусти его, если среда совместима и запуск разрешён.
4. Внеси исправление в разрешённые файлы. Повтори подходящие тесты. Различай: тест предложен, тест фактически выполнен, результат неизвестен. Если запуск недоступен, дай patch и точную команду человеку, без заявления «тесты прошли».
5. Покажи diff и ограничения проверки. До моего согласования не выполняй запись в GitHub.
6. После согласования предложи отдельные формы для создания ветки, записи файлов/коммита и открытия PR. Проверь repo, base и head в каждой форме. Если операция недоступна, остановись и сообщи об этом.
7. В PR опиши проблему, новое поведение и фактическую проверку. Прочитай доступные статусы CI; не называй ожидание успешным прохождением.
8. Верни ссылку на созданный PR либо fix.patch, тест и verification.txt для ручного переноса.
Не сливай PR, не развёртывай изменения и не трогай другие репозитории.

Разбор на маленьком модуле

Учебный пример подготовлен для статьи. Код и тесты выполнены локально при её подготовке; это не запись запуска Искры и не настоящий GitHub PR.

Было

start_day <= date.fromisoformat(order["date"]) < end_day

Стало

start_day <= date.fromisoformat(order["date"]) <= end_day

В исходном модуле два из пяти тестов воспроизводят ошибку. Исправленный эталон проходит все пять. Полный локальный отчёт и минимальный patch доступны для сравнения.

cd example-input
python3 -m unittest -v

# Для проверки эталона перейдите в example-expected
# и выполните ту же команду.

Что поместить в описание PR

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

Что проверить до принятия PR

• Repo, базовая ветка и исходная ревизия соответствуют задаче; в diff нет чужих изменений и секретов.
• Тест воспроизводит пользовательскую ошибку и проверяет границы, а не только повторяет код функции.
• Вы знаете, где запускались проверки: среда Искры, ваш компьютер или GitHub CI. Статусы не смешаны.
• Если код работает с датой и временем, отдельно проверены часовые пояса. Учебное исправление для календарных дат нельзя бездумно переносить в такой проект.
• Слияние и выпуск проверяет ответственный разработчик. Создание PR само по себе не подтверждает готовность к продакшену.

Что сделать дальше

Чем агентская задача полезна разработчику

Полезный результат включает цепочку доказательств: наблюдаемая ошибка, причина, минимальное изменение, проверка и удобный diff. Программисту проще оценить такое изменение, чем переносить отдельный фрагмент кода из ответа.

Доступ к GitHub через API позволяет работать с файлами и PR. Он не даёт автоматически среду проекта, локальную IDE, установленные зависимости и успешный CI. Эти условия нужно определить до запуска задачи.

Связанные материалы

• ИИ для программиста
• Как перенести код на другой язык и сохранить поведение