Apply Pilot — проект поиска работы

Apply Pilot — проект поиска работы

Суть

Apply Pilot — проект по поиску работы, который Павел ведёт вместе с ещё одним программистом. По словам Павла, проект уже содержит практические наработки, похожие на многоагентную разработку automation-проектов: промпты, доработки, агентоподобное разделение работы и MR, собранный Opus. ^{источник}

Роль Павла

Важное ограничение контекста: Павел не является инициатором, методологическим владельцем и продуктовым владельцем этого проекта. Он выступал своими ресурсами и знает часть проекта, но не владеет им в полной мере. Поэтому Apply Pilot нужно рассматривать как внешний/совместный живой кейс, а не как полностью управляемый Павлом проект. ^{источник}

Почему важен для исследования

Apply Pilot — потенциально сильный case study для нашей методологии:

• домен понятный: поиск работы и автоматизация откликов;
• уже есть реальные MR/код/промпты;
• разработка частично шла с LLM/Opus;
• есть признаки spec-driven агентной разработки, но методология, судя по описанию, не оформлена явно;
• можно сравнить фактический процесс с каркасом project → spec → plan → tasks → implement.

Как разбирать Apply Pilot

Когда появится доступ к MR/репозиторию/patch, разбор делать не просто как code review, а по схеме:

1. Project — кто владелец, какие цели, ограничения, стек, зоны ответственности. 2. Spec — какая фича или изменение требовались. 3. Plan — как Opus/разработчики разложили работу. 4. Tasks — какие отдельные work packages видны в diff/commit history. 5. Implement — что реально вошло в MR. 6. Review / QA — какие тесты, CI, human review, security checks были или отсутствовали. 7. Lessons — какие паттерны перенести в методологию многоагентной разработки.

Открытые вопросы

• Какие именно промпты используются в проекте?
• Есть ли spec/plan/tasks артефакты или они живут только в переписке/промптах?
• Какой стек проекта и какие внешние сервисы задействованы?
• Что именно сделал MR !653, собранный Opus?
• Какие quality gates сейчас есть: tests, CI, review, ручные проверки?
• Где граница ответственности Павла, второго программиста и AI-агентов?

Актуальное состояние на 2026-10-17

Серверное развёртывание закрыто после подтверждённого переноса на локальный компьютер Павла. С сервера удаляются рабочая копия, контейнеры, Docker-тома, локальная БД, Redis, незашифрованный .env, SOPS age-ключ, архивы миграции, локальные логи разработки и временные файлы. Каноническими местами хранения остаются локальный компьютер и GitLab-репозиторий apply-pilot-team/apply-pilot; секреты в базу знаний не переносятся.

Последнее серверное состояние перед выводом из эксплуатации:

• ветка main, commit 9a4a83644dd90bb8d77b843808da65de0ed1766c;
• Docker Compose-контур: API, PostgreSQL, Redis, Telegram bot, MAX bot, scheduler и одноразовые Alembic migrations;
• стек: Python 3.13, FastAPI, SQLAlchemy 2.x, Alembic, PostgreSQL, Redis, uv, Docker Compose;
• интерфейсы: React/web, Telegram и MAX;
• первый источник вакансий — hh.ru с архитектурной возможностью подключать новые источники;
• конфигурация секретов — SOPS + age; открытые значения секретов в wiki намеренно отсутствуют.

Основные продуктовые направления

1. Точечный поиск работы вместо массовых откликов. Пользователь задаёт карьерные цели и резюме, а система собирает и ранжирует только релевантные вакансии. 2. Многоканальный сбор вакансий. hh.ru — первый источник; модель данных и интеграционный слой рассчитаны на расширение. 3. AI-оценка соответствия. Быстрый фильтр дополняется глубоким сопоставлением вакансии, резюме и карьерных целей с объяснением результата. 4. Подготовка отклика. Система создаёт и версионирует сопроводительные письма, ответы на вопросы и черновики; пользователь может запросить перегенерацию с комментарием. 5. Human-in-the-loop. Решение об отправке остаётся за пользователем: принять, отклонить, отложить или вернуть на доработку. 6. Обзор и уведомления. Telegram/MAX и web-интерфейс используются для ежедневных дайджестов, ревью вакансий и контроля статусов. 7. Планирование и фоновые процессы. Scheduler и worker разделяют сбор, анализ, подготовку и отправку задач. 8. Безопасность и приватность. Self-hosted контур, минимизация передачи персональных данных внешним LLM, шифрование секретов и явные production-настройки.

Инженерная методология

• Любое изменение проходит путь issue → отдельная ветка/worktree → тесты → merge request → review → merge; прямые изменения main запрещены.
• Для существенных решений ведутся ADR; архитектурный контекст хранится рядом с кодом.
• Основная структура приложения — FastAPI-монолит с вертикальными срезами; инфраструктурные процессы развёрнуты отдельно.
• Для read-heavy анализа используются субагенты, а основной агент сохраняет за собой решения, изменения, MR и финальный контроль.
• Проект полезен как живой пример spec-driven разработки и многоагентной методологии.

Вывод из серверной эксплуатации

Причина закрытия серверного контура — перенос проекта на компьютер Павла и освобождение серверного диска. Это не прекращение проекта: меняется только место исполнения и хранения. При возможном возврате на сервер следует заново развернуть код из GitLab, восстановить данные с локального компьютера и выпустить/подключить секреты через SOPS + age; старые секреты из этой базы восстановить нельзя и не нужно.

Связанные заметки

• Spec-driven агентная разработка
• Методология многоагентной разработки automation-проектов
• Роли агентов для automation-проектов
• job_search