Я заплатил за Claude Max, но оригинальный проект ccpocket убрал OAuth-авторизацию - и я не хочу платить за токены дополнительно. За 11 промптов я создал форк с собственной OAuth-авторизацией, который автоматически подтягивает релизы upstream и делает отдельный релиз для меня.
Форк как обуза
ccpocket - это по сути мобильный Claude Code. Открываешь на телефоне, работаешь с агентом как в чате. Я активно контрибьютил в проект, а потом владелец решил убрать OAuth-авторизацию. Правила Anthropic разрешают OAuth для доступа к API с подпиской Max - но владелец решил, что безопаснее без неё.
Варианты у меня были простые: платить за токены поверх уже оплаченного Max, или делать форк. Форки пугают именно тем, что начинаются легко, а потом превращаются в постоянный maintenance. Upstream выпускает новую версию - ты либо тратишь час на ручное обновление, либо просто откладываешь. Потом откладываешь ещё раз. Форк начинает отставать на несколько версий и превращается в мёртвый груз.
Так казалось.
Patch-based подход вместо merge
Классический форк - это ветка от upstream, в которой ты делаешь изменения. При каждом обновлении - либо merge с кучей мёрж-коммитов, либо rebase с риском конфликтов. История разрастается, трудно понять что вообще твоё, а что пришло из upstream.
Я выбрал другой путь: patch-based подход. Мои изменения живут отдельно в виде патчей. Патч - текстовый файл, описывающий разницу. Когда выходит новый upstream релиз, автоматика берёт чистый upstream и накладывает мои патчи поверх. Применились без конфликтов - сразу выходит новый релиз форка.
Это не изобретение. git format-patch существует с первых версий Git. Linux kernel до сих пор живёт на патчах по email. StGit - инструмент для управления стеками патчей - активно развивается, последняя версия вышла в начале этого года. Просто для личных проектов этот подход используют реже, чем стоило бы.
Для форка с несколькими патчами это идеальный вариант. Чистая история, легко понять что изменено, легко переносить изменения между версиями.
11 промптов с Claude Code
Весь форк ccpocket-oauth-auth я сделал с AI-агентом. 11 промптов - это не мало и не много для начальной настройки. Установочная фаза требует времени, потом maintenance становится гораздо дешевле.
Структура репозитория. Первые несколько промптов ушли на то, чтобы разобраться как хранить патчи. Выбрал папку patches/ с нумерованными файлами и файлом series который задаёт порядок применения - это Quilt-стиль, понятный любому кто работал с Debian-пакетами. Патчей у меня немного: это возвращение OAuth-авторизации, не больше.
GitHub Actions для синхронизации. Центральная часть. Workflow срабатывает по расписанию и проверяет upstream на новые релизы. Если появился новый релиз - берёт чистый код, применяет мои патчи через git am, прогоняет тесты. Прошло - создаётся PR для ревью. Конфликтует - тоже PR, но с описанием проблемы, чтобы я мог разобраться руками.
- name: Apply patches
run: |
git am patches/*.patch || {
echo "Conflicts detected"
git am --abort
exit 1
}
Версионирование. Мой форк получает версию вида v1.2.3-oauth.1. Первая часть - версия upstream, суффикс oauth и порядковый номер - моя итерация. Changelog генерируется автоматически из коммитов.
Тестирование и документация. Последние промпты - убедиться что OAuth работает после применения патчей, и написать README для тех кто захочет использовать форк.
Три компонента паттерна
Если выдернуть из этого кейса переносимый паттерн, получаются три компонента.
Patch Management. Папка patches/ с нумерованными файлами, файл series с порядком применения. Каждый патч - одна логическая задача. Патчи версионируются вместе с кодом, так что в истории репозитория видно как они менялись.
Automated Sync. GitHub Actions по расписанию проверяет upstream. git fetch upstream, сравнение тегов, если есть новый релиз - применить патчи и прогнать тесты. PR-mode здесь важнее чем автоматический push в main: лучше лишний раз посмотреть что произошло, особенно если upstream выпустил что-то неожиданное.
Auto-Release. Если патчи применились и тесты прошли - создаётся релиз с версией {upstream-version}-oauth.{n}. Пользователи форка получают обновления автоматически.
Всё это работает без моего участия. Я мог бы узнать о новом релизе ccpocket через неделю - и мой форк уже бы его подхватил.
Когда это перестаёт работать
Я держу три-пять патчей. Это комфортная зона - конфликты случаются редко и разрешаются быстро.
При шести-двадцати патчах стоит добавить StGit. stg rebase upstream/main автоматически пробует наложить весь стек на новый base, разрешая конфликты через 3-way merge. Там где git am просто падает, StGit пытается разобраться сам - это принципиальная разница при большом стеке.
При пятидесяти и больше патчах - это уже не форк, это фактически отдельный проект. Fedora использует специализированный Packit workflow для автоматизации релизов и управления downstream патчами при подготовке дистрибутива, но это enterprise-уровень с выделенными людьми. Для личного проекта лучше либо активнее контрибьютить в upstream, либо признать что ведёшь самостоятельный проект.
Магия форка-как-расширения работает именно потому что он маленький.
AI-агент в процессе форк-синхронизации
Claude Code помог в трёх конкретных местах.
Первое - само создание workflow. Я мог бы написать GitHub Actions YAML руками, это не сложно. Но с агентом я описал что хочу (“синхронизировать upstream, применять патчи, создавать релиз”) и получил рабочий черновик за один промпт. Потом несколько итераций на уточнение деталей.
Второе - конфликты при применении патчей. Когда git am упал, агент читал контекст конфликта и предлагал как его разрешить. Не всегда правильно, но как точка отсчёта - полезно.
Третье - документирование патчей. Каждый патч должен иметь понятное описание: зачем он существует, почему не ушёл в upstream, на что обратить внимание при конфликте. Агент хорошо справляется с такими комментариями если ему показать сам патч.
11 промптов на старте - это нормально. Потом maintenance требует промпта примерно раз в месяц, когда что-то конфликтует. Всё остальное автоматическое.
Результат
ccpocket-oauth-auth существует, OAuth-авторизация работает, синхронизация с upstream автоматическая. Я использую Claude Code с телефона, не плачу за токены поверх уже оплаченного Max.
Если upstream выпустит сто релизов - мой форк получит сто релизов. Моё участие требуется только когда patch конфликтует с новым кодом. За всё время с момента запуска это случилось один раз.
git format-patch и git am - инструменты из стандартного Git. GitHub Actions - стандартная автоматизация. Сложность была не в технологии, а в том чтобы сесть и сделать.