FastCV

AI-биржа вакансий. Вакансии собираются из Telegram-каналов и нормализуются нейросетью. Кандидат откликается в один клик с сопроводительным письмом, которое пишет ИИ под конкретную вакансию. Работодатели публикуют вакансии напрямую и разбирают отклики в своём кабинете.

Как устроено

Часть	Где	Что делает
Сайт	src/	Next.js 16 + Tailwind. Лента с фильтрами, Smart Apply, кабинеты кандидата и работодателя
API писем	src/app/api/cover-letter	Генерирует сопроводительное через Gemini. Только для вошедших, с лимитом запросов
Сборщик	main.py	Раз в 6 часов (GitHub Actions) забирает новые посты из каналов таблицы channels, нормализует их через Gemini и сохраняет вакансии со ссылкой на оригинал
База	supabase/migrations/	Таблицы, триггеры и правила доступа (RLS) для Supabase, по миграциям

Роли. Роль (candidate или employer) выбирается при регистрации и потом не меняется: это гарантирует триггер в базе. Работодатель попадает в /employer, кандидат — на главную и в /applications.

Запуск локально

1. Установите Node.js 20+ и Python 3.11+.
2. Скопируйте .env.example в .env.local и заполните ключи.
3. Примените схему базы: Supabase → SQL Editor → по очереди выполните файлы из supabase/migrations/ (по возрастанию имени). Базовую миграцию безопасно запускать повторно.
4. Запустите сайт:

   npm install
   npm run dev
   

   Сайт откроется на http://localhost:3000.
5. Сборщик (по желанию):

   pip install -r requirements.txt
   python main.py
   

   Каналы для парсинга добавляются в таблицу channels (username, is_active = true). Тесты сборщика (без сети): python -m pytest -q tests.
6. Тесты правил доступа к базе (нужны Postgres 15+ и psql; база fastcv_test пересоздаётся):

   FASTCV_DB_TESTS=1 PGHOST=localhost PGUSER=postgres PGPASSWORD=postgres python -m pytest -v tests/db
   

   В CI они идут на каждый PR вместе с тестами сборщика и сборкой сайта. Lighthouse (скорость и доступность fastcv.ru на мобильном) запускается после каждого выката в продакшн; баллы приходят комментарием к коммиту.

Изменения базы

Каждое изменение схемы — новый файл supabase/migrations/<ГГГГММДДччммсс>_<что_меняем>.sql. Файлы применяются по возрастанию имени; уже применённые не правятся.

1. Напишите миграцию и прогоните тесты правил доступа (они применяют все миграции к чистой базе).
2. Примените её к тестовой базе (staging), затем к рабочей — через Supabase CLI (supabase db push) или SQL Editor, тем же содержимым файла.
3. Обновите типы (npm run db:types).

Миграции, изменяющие данные, пишите так, чтобы повторный запуск ничего не ломал (create ... if not exists, create or replace, проверки в do $$ ... $$).

Новая таблица — сразу с grant. Supabase больше не выдаёт права на новые таблицы автоматически: без явного grant select, insert, … to authenticated правила RLS ничего не открывают, и запросы молча возвращают ошибку. Тест «у каждого правила RLS есть права на таблицу для его роли» ловит это до слияния.

Типы базы

Типы таблиц для TypeScript лежат в src/lib/database.types.ts и генерируются из схемы. После новой миграции обновите их (нужен Supabase CLI и supabase login):

npm run db:types

Клиенты Supabase типизированы этими типами: опечатка в имени колонки или неверный тип значения ловится на npx tsc --noEmit и в CI.

Как работает сборщик

• Только новые посты. Для каждого канала хранится last_post_id. Сборщик берёт посты новее него и, если с прошлого запуска вышло больше страницы, листает историю назад (до 5 страниц, около 100 постов). Новый канал начинается с 10 последних постов.
• Без дублей. Вакансия привязана к посту (source_post = канал/id), поэтому отредактированный пост не создаёт вторую запись. Одинаковый текст в разных каналах отсекается по хешу.
• Gemini по JSON-схеме. Модель возвращает структуру вакансии, компанию, валюту зарплаты и список технологий (stack). Модели перебираются по очереди (gemini-3.1-flash-lite → gemini-3.5-flash-lite → gemini-3.6-flash, переопределяется переменной GEMINI_MODELS): если одна перегружена (503), упёрлась в лимит (429) или снята с поддержки (404), запрос уходит в следующую. Таймаут запроса — 60 секунд. Если не ответила ни одна, канал останавливается на этом посте и продолжит с него в следующий запуск; после трёх таких каналов подряд остальные откладываются целиком.
• Архив. Вакансии из Telegram старше 30 дней получают archived_at и пропадают из ленты. Данные не удаляются. Вакансии прямых работодателей не архивируются.
• Недоступные каналы. Если у канала закрыт веб-просмотр, растёт счётчик failed_runs, а причина пишется в last_error. Список таких каналов выводится в конце лога.

Telegram-боты

Ботов два, у каждого свой токен:

Бот	Токен	Для чего
Оповещения	TELEGRAM_BOT_TOKEN + TELEGRAM_CHAT_ID (секреты GitHub)	сбои сборщика и утренняя сводка — только владельцу
Подборки	TELEGRAM_JOBS_BOT_TOKEN (Vercel, Production + секрет GitHub)	кандидатам: привязка чата и новые подходящие вакансии

Бот подборок отвечает сразу: Telegram присылает сообщения на /api/telegram/webhook (подпись — заголовок X-Telegram-Bot-Api-Secret-Token). Webhook и имя бота для ссылки в профилях настраивает кнопка «Подключить бота подборок» в /admin; после смены токена её нужно нажать снова. Подборки рассылает сборщик после каждого запуска.

Демо

Перед показом демо-аккаунты возвращаются в исходное состояние одной кнопкой: Actions → Demo Reset → Run workflow (или python demo_reset.py с переменными SUPABASE_URL, SUPABASE_SERVICE_ROLE_KEY, DEMO_CANDIDATE_EMAIL, DEMO_EMPLOYER_EMAIL). Сбрасываются отклики, письма, отметки и лимиты ИИ демо-кандидата; профиль кандидата очищается (кроме имени — на показе его заполняет ИИ по резюме), три вакансии демо-работодателя создаются заново (функция reset_demo). Аккаунты заводятся обычной регистрацией на сайте, их адреса — в переменных репозитория DEMO_CANDIDATE_EMAIL и DEMO_EMPLOYER_EMAIL.

Окружения

	База Supabase	Сайт
Рабочее	First_DB (wyanvkaoqxgceaxzlqvk)	fastcv.ru — ветка main
Тестовое (staging)	fastcv-staging (zcyccnlweanhcsumplbx)	превью Vercel для каждого PR

Превью и локальная разработка (vercel env pull) ходят в тестовую базу: регистрация, отклики и эксперименты на превью не трогают рабочие данные. Миграции сначала применяются к тестовой базе, потом к рабочей.

Деплой

• Сайт (Vercel): задайте NEXT_PUBLIC_SUPABASE_URL, NEXT_PUBLIC_SUPABASE_ANON_KEY и GEMINI_API_KEY в Environment Variables. В NEXT_PUBLIC_SUPABASE_ANON_KEY — только публичный ключ (sb_publishable_… или anon): всё с префиксом NEXT_PUBLIC_ попадает в браузер. С секретным ключом сборка остановится. Переменные NEXT_PUBLIC_* вшиваются при сборке, поэтому после их изменения нужен редеплой.
• Сборщик (GitHub Actions): секреты NEXT_PUBLIC_SUPABASE_URL, SUPABASE_SERVICE_ROLE_KEY и GEMINI_API_KEY.
• Supabase → Authentication → URL Configuration: добавьте https://<ваш-домен>/auth/callback в Redirect URLs, чтобы работала ссылка подтверждения почты.