Пролог: боль, из которой всё началось

В 2026 году я пошёл искать новую работу.

Сначала всё просто: открыл сайты с вакансиями, выбрал интересные, откликнулся, жду ответов.

Через несколько дней это кончилось.

У меня уже 40 вкладок. Часть вакансий в избранном, часть прилетела в телегу, несколько ссылок потерялись в переписках. Была таблица — начал вести, бросил через 3 дня.

А потом главное. Я на эту вакансию уже откликался или только собирался? Где ждёт ответ, где надо писать follow-up, что уже неактуально?

Короче, это уже не поиск работы. Это маленькая CRM для собственной тревожности.

Так появился JobTrack — штука, которая отслеживает вакансии и что я с ними делал.

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

Тут первая нормальная развилка: либо дальше фантазировать про большой продукт для всех, либо сжать хаос до проверяемой гипотезы. И вот это — правильная точка старта.

Не рынок вообще, не продукт для всех. А я, 40 вкладок, брошенная таблица и один вопрос: что мне сейчас делать с этой вакансией?

Мини-глоссарий

Этот мини-глоссарий собран на базе публичного AI-глоссария TechCrunch, но адаптирован для курса. Здесь не весь словарь ИИ, а только термины, которые встретятся в модуле.

• ИИ: системы, которые помогают анализировать, писать, искать, классифицировать и принимать решения. В этом курсе ИИ — инструмент мышления и проверки, а не автор продукта вместо тебя.
• LLM: большая языковая модель. Это тип модели, с которой ты общаешься в ChatGPT, Claude, Gemini и похожих инструментах.
• Запрос или prompt: формулировка задачи для ИИ. Чем точнее контекст, роль, ограничения и ожидаемый формат ответа, тем полезнее результат.
• AI-агент: ИИ-инструмент, который может выполнять несколько шагов подряд и пользоваться внешними инструментами: файлами, браузером, терминалом, API.
• Галлюцинация: уверенный, но неверный ответ ИИ. Поэтому выводы из ИИ нужно проверять источниками, особенно рынок, право, цены, API и ограничения площадок.
• API: официальный способ для одного сервиса дать другому данные или действие. Если у job-сайта есть API, это обычно безопаснее и устойчивее, чем забирать данные со страниц.
• Deep research: глубокое исследование через ИИ и поиск. Это не один вопрос, а серия проходов: сегмент, конкуренты, альтернативы, жалобы пользователей, ограничения, источники.
• Scraping или парсинг страниц: автоматический сбор данных с сайтов. Перед таким решением нужно проверять правила площадки, robots.txt, API, персональные данные и согласие пользователя.

Перед стартом: где живут настройки агента

В этом курсе ты будешь часто просить ИИ спорить, критиковать, резать scope и помогать с файлами. Начинать каждый новый чат с объяснения, кто ты и как с тобой говорить, — трата времени. Базовые настройки агента лучше держать отдельно.

Для этого есть отдельный дополнительный материал: AI Settings и настройки агентов. Там разобрано, что такое репозиторий глобальных AI-настроек, почему его нужно адаптировать под себя и почему не стоит держать правила только внутри одного продукта вроде Codex, Claude или Cursor.

Ещё до первой практики поставь Super Puper Powers, или SPP, в выбранный coding agent. Подробно skills и workflow разберём в модуле 6, но базовый смысл нужен уже сейчас.

SPP — это не новая модель и не волшебная кнопка. Это рабочие инструкции для агента: сначала понять задачу, выбрать процесс, не писать код раньше времени, проверить результат и не объявлять готово без evidence.

Команда /spp нужна как вход в этот процесс. Она заставляет агента остановиться и выбрать подходящий workflow, а не уверенно додумать задачу и побежать писать код.

На первых модулях SPP работает без кода приложения: агент помогает формулировать гипотезу, discovery и scope, ведёт брифы и pipeline-state.md, но не начинает реализацию продукта. Поэтому установка в начале курса — не ритуал, а ремень безопасности.

Без SPP дальше придётся руками повторять каждый запрет: не расширяй MVP, не пиши код, сначала задай вопросы, верни артефакт.

Формулировка гипотезы — это фаза 0 SPP, скилл idea-intake: он собирает бриф идеи.

SPP держит память о проекте в docs/spp/pipeline-state.md: что за продукт, что уже сделано, какие решения приняты. Поэтому работу можно прервать и продолжить в новой сессии. Следующий модуль — следующая фаза того же pipeline, а не отдельный разрозненный шаг.

Сейчас не нужно разворачивать всё идеально. Достаточно понять принцип: модель — инструмент, а рабочие правила и контекст должны жить в файлах, которые ты контролируешь.

Зачем нужен этап

Идея продукта — это гипотеза. Не план разработки.

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

Этап гипотезы нужен, чтобы превратить туманную идею в проверяемое предположение. После этого можно идти в discovery, задавать вопросы людям и уточнять продукт, а не защищать красивую фантазию.

На этом же этапе стоит быстро посмотреть рынок и конкурентов. Если готовое решение уже существует, это не значит, что продукт делать нельзя. Это значит, что нужно понять, чем твоя гипотеза отличается: сегментом, сценарием, ценой, простотой, каналом или конкретной болью.

Ещё важно заранее найти ограничения и узкие места, о которых легко не знать в начале. Например, JobTrack может упереться не в интерфейс, а в ручное обновление статусов, импорт вакансий, приватность данных или привычку пользователя держать поиск работы в Telegram и таблицах.

Размыт хоть один ответ — продукт поедет во все стороны сразу. На выходе получится не MVP, а комбайн, который не решает нормально ни одну боль.

Preflight перед discovery

В этом модуле не нужно проводить полный discovery: полный discovery начнётся в следующем модуле. Там будут разговоры с людьми, факты, альтернативы и уточнение гипотезы.

Здесь нужен preflight — короткая проверка перед discovery. Его задача простая: не идти к людям с совсем сырой формулировкой и не строить MVP на очевидно слабом или рискованном основании.

1. Обсуждение решения с ИИ

Сначала проговори идею с ИИ как с оппонентом и аналитиком. Пусть разложит её на пользователя, боль, сценарий, ценность и сигнал успеха.

Пример запроса для JobTrack:

Я хочу сделать JobTrack: сервис для соискателей, которые теряют вакансии и статусы откликов. Разложи идею на пользователя, боль, сценарий, ценность и сигнал успеха. Предложи 3 более узкие гипотезы.

Пример ответа:

Пользователь: активный соискатель, который откликается на 10–20 вакансий в неделю. Боль: вакансии, статусы и следующие действия расползаются по вкладкам, Telegram и таблицам. Сценарий: быстро сохранить вакансию, поставить статус, увидеть следующий шаг. Ценность: не терять важные действия и не тратить вечер на уборку списка. Сигнал успеха: пользователь возвращается в JobTrack 3–4 раза в неделю и обновляет статусы без напоминаний.

Варианты более узких гипотез:

• JobTrack для активных соискателей, которые ведут 10+ откликов параллельно;
• JobTrack для разработчиков, которые получают вакансии из Telegram-каналов и личных сообщений;
• JobTrack для людей, которые уже пробовали таблицы, но бросили их из-за ручного обновления.

Смысл шага — быстро получить несколько формулировок и увидеть, где идея слишком общая.

2. Критика идеи

После первой формулировки не проси ИИ подтвердить, что идея хорошая. Это бесполезно: он подтвердит почти что угодно, если его нормально не прижать.

Нужна критика.

Пример запроса:

Покритикуй идею JobTrack. Почему активный соискатель может не захотеть пользоваться таким сервисом? Какие привычки, альтернативы и ограничения могут убить продукт?

Пример ответа:

Риск 1: пользователь уже живёт в таблице или Notion и не хочет переносить процесс. Риск 2: ручное добавление вакансий быстро надоест. Риск 3: часть вакансий приходит из Telegram, личных сообщений и закрытых каналов, откуда трудно сделать удобный импорт. Риск 4: соискатель вспоминает про трекер только когда уже потерял контекст. Риск 5: продукт может стать ещё одним местом, которое нужно обслуживать.

Нормальная критика вскрывает неприятное: людям может хватать таблицы, переносить данные вручную они не хотят, а часть вакансий живёт в закрытых каналах и переписках.

3. Запрос на узкие места

Теперь найди узкие места реализации и поведения — места, где продукт сломается не в презентации, а в жизни.

Пример запроса:

Какие узкие места есть у JobTrack: данные, приватность, импорт вакансий, обновление статусов, удержание пользователя, мобильный сценарий, юридические ограничения?

Пример ответа:

Самое узкое место — не список вакансий, а поддержание актуальности. Если пользователь должен вручную обновлять всё после каждого сообщения от рекрутёра, он быстро бросит продукт. Второе узкое место — приватность: в вакансиях и переписках могут быть компании, зарплаты, контакты и личные заметки. Третье — мобильный сценарий: многие вакансии приходят не за рабочим ноутбуком, а в телефоне. Четвёртое — юридический риск: если JobTrack собирает данные с job-сайтов, нужно проверить правила площадок, доступные API, ограничения на автоматический сбор, хранение персональных данных и согласие пользователя.

Так заранее видно: главный риск не в том, как нарисовать список вакансий. Он в том, что пользователю лень поддерживать список актуальным, а данные нельзя собирать выбранным способом.

Юридические ограничения проверь отдельно.

Пример запроса:

Я хочу, чтобы JobTrack забирал вакансии и статусы с job-сайтов. Составь карту юридических и продуктовых вопросов, которые нужно проверить до разработки: правила площадок, API, robots.txt, scraping, персональные данные, пользовательское согласие, хранение данных, риски блокировки. Не давай финальный юридический вывод, а перечисли, какие документы и факты нужно проверить.

Пример ответа:

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

4. Быстрый ресерч рынка

Посмотри, какие готовые решения уже есть: таблицы, Notion-шаблоны, Trello-доски, CRM для поиска работы, расширения браузера, приложения для трекинга откликов.

Но перед глубоким исследованием нужно уточнить сегмент.

Рынка поиска работы вообще не существует как одного сценария. Есть джуны, мидлы, синьоры, релоканты, фрилансеры, люди после сокращения, люди с офферами, пассивные кандидаты и активные соискатели. У них разные боли, каналы, цена ошибки и привычки.

Плохой запрос:

Исследуй рынок сервисов для поиска работы.

Лучший запрос:

Исследуй рынок инструментов для активных IT-соискателей в России, которые откликаются на 10+ вакансий в неделю и получают вакансии из job-сайтов, Telegram и личных сообщений. Сравни таблицы, Notion-шаблоны, Trello, CRM-подход и специализированные трекеры откликов. Отдельно найди, где пользователи жалуются на ручное обновление и потерю статусов.

Пример ответа:

Основные альтернативы: Google Sheets, Notion-шаблоны, Trello-доски, встроенные статусы на job-сайтах и ручные заметки в Telegram. Сильная сторона таблиц — гибкость. Слабая — дисциплина и ручное обновление. Job-сайты помогают только внутри своей площадки и не видят вакансии из Telegram. Возможная ниша JobTrack — единый трекер для активного поиска, где главная ценность не хранение вакансий, а снижение ручной работы.

Где запускать такой ресерч:

• в ChatGPT, Claude или другом ИИ с веб-поиском — быстро собрать карту рынка, альтернативы, паттерны жалоб и первичные гипотезы;
• в Perplexity, Google или Яндексе — проверить источники вручную, найти реальные продукты, отзывы, документацию и условия использования;
• на сайтах конкурентов — руками посмотреть онбординг, цены, ограничения, импорт, экспорт, мобильные сценарии;
• в каталогах шаблонов и комьюнити — увидеть не только продукты, но и ручные обходные решения: таблицы, Notion-шаблоны, чеклисты, Trello-доски.

Deep research лучше гнать в несколько проходов:

1. Карта рынка и сегментов.
2. Конкуренты и альтернативы.
3. Критика найденных решений.
4. Ручная проверка источников.
5. Вывод: где рынок занят, где есть неудобство, какую гипотезу проверять первой.

В этом модуле хватит короткой preflight-версии. Времени мало — сделай первые 2 прохода и запиши, что осталось проверить в модуле discovery.

Доказать, что конкурентов нет, не задача. Они почти всегда есть.

Задача — понять, какой сценарий они закрывают, где у них лишняя сложность, что пользователи обходят вручную и где влезает твоя гипотеза.

Для JobTrack вывод может быть такой: рынок не пустой, но многие решения требуют дисциплины и ручного обновления. Значит, гипотеза должна проверять не хранение вакансий, а снижение цены обновления.

5. Подготовка к разговорам с людьми

После ИИ и ресерча всё равно нужны разговоры с потенциальными пользователями. В этом модуле их проводить не нужно. Сейчас задача — подготовить гипотезу так, чтобы в следующем модуле было понятно, кого спрашивать и о чём.

В разговорах спрашивай не про будущий JobTrack, а про текущую жизнь человека: где он хранит вакансии, что забывает, как понимает следующий шаг, какие инструменты уже бросил.

6. Уточнение гипотезы

После критики и ресерча рынка гипотеза становится точнее. Разговоры с людьми начнутся в следующем модуле и проверят её на фактах.

Было:

JobTrack помогает искать работу.

Стало:

JobTrack помогает активному соискателю поддерживать актуальный список вакансий и статусов без вечерней уборки вкладок, таблиц и переписок.

Что меняется после этапа

До этапа у Бориса есть идея JobTrack: сделать удобный сервис для поиска работы.

После этапа у него есть MVP-гипотеза:

• кто первый пользователь;
• какая конкретная боль у него есть;
• какой сценарий проверяет продукт;
• какую ценность пользователь должен получить;
• по какому сигналу станет понятно, что гипотеза работает.

Это ещё не истина, а стартовая версия. Дальше её проверяем.

Принцип

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

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

Теория на примере JobTrack

Плохая формулировка JobTrack:

JobTrack помогает искать работу.

Непонятно ничего: кому, в каком сценарии, какую боль снимает, как измерить успех.

Рабочая формулировка:

Если активный соискатель сможет быстро сохранять вакансии и видеть статус каждого отклика, он перестанет терять следующие действия, а сигналом будет регулярное обновление списка без возврата к 40 вкладкам.

Разложим:

• первый пользователь: активный соискатель;
• сценарий: сохранять вакансии и вести статусы откликов;
• ценность: не терять следующие действия;
• сигнал: человек возвращается в JobTrack и обновляет список.

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

Результат ученика

Результат этого блока — первый учебный черновик раздела Гипотеза MVP в docs/discovery.md. В реальный файл проекта ты перенесёшь его в модуле 4.

Идеальным он быть не должен. Нужна формулировка, ясная настолько, чтобы в следующем модуле проверить её разговорами с людьми.

Работаем дальше.

Сформулируй первую гипотезу для своего продукта так, как Борис формулирует JobTrack.

Не описывай весь будущий продукт. Это ловушка: пока описываешь всё, ты не проверяешь ничего. Нужна одна проверяемая ставка: кто страдает, в каком сценарии, какую ценность получает и как ты поймёшь, что стало лучше.

После этого проверь, что гипотеза не висит в воздухе: сегмент уточнён, рынок быстро просмотрен, узкие места выписаны, а первый MVP не начинается с рискованного сбора данных.

Полное discovery будет позже. Сейчас нужен preflight: короткая проверка перед следующим модулем.

Шаг 0. Выбери и настрой инструмент

Весь курс ты работаешь через coding agent — ИИ, который умеет не только отвечать в чате, но и создавать файлы, менять код и выполнять команды. Канон курса — два инструмента. Выбери один и держись его до конца, иначе потом сам устроишь себе зоопарк из разных привычек и настроек.

• Дорожка A — Codex App: приложение с обычным окном, без терминала. Бери, если не хочешь иметь дело с командной строкой.
• Дорожка B — Claude Code: работа через терминал. Бери, если готов набирать команды и хочешь больше контроля.

Оба инструмента проходят весь курс одинаково. Дальше, где шаги отличаются, будет пара «дорожка A / дорожка B» — выполняй только свою. Другие инструменты (Cursor, Windsurf, Gemini CLI и прочие) тоже существуют, но курс их не проверяет: берёшь такой — на свой риск, сверяйся с его документацией сам.

Дорожка A. Codex App

1. Аккаунт и тариф. Codex работает по подписке OpenAI. Заведи аккаунт на официальном сайте OpenAI и проверь, что у тебя есть доступ к Codex.
2. Установка. Скачай Codex App с официальной страницы под свою ОС, установи как обычное приложение и войди в аккаунт.
3. Первая проверка. Открой Codex App и напиши в чате:

   Ты видишь это сообщение? Ответь одним предложением и ничего больше не делай.
   

   Успех: агент отвечает коротким сообщением.
4. Если не получилось. Не двигайся дальше. Проверь подписку, регион доступа и вход в аккаунт. Если Codex App недоступен в твоём регионе — это нормальная причина выбрать дорожку B.

Дорожка B. Claude Code

Claude Code работает в терминале. Терминал — это окно, где команды набирают текстом, а не кликами. На Mac он называется «Терминал», на Windows подойдёт «PowerShell» или «Terminal». Открой его один раз, чтобы увидеть, как он выглядит: строка приглашения и мигающий курсор. Больше про него знать пока не нужно.

1. Аккаунт и тариф. Claude Code работает по подписке Anthropic. Заведи аккаунт на официальном сайте Anthropic.
2. Установка. Открой терминал и установи Claude Code по официальной инструкции Anthropic. Следуй тому, что написано на официальной странице, — не копируй команды из случайных статей.
3. Первая проверка. Запусти Claude Code в терминале и напиши:

   Ты видишь это сообщение? Ответь одним предложением и ничего больше не делай.
   

   Успех: агент отвечает коротким сообщением.
4. Если не получилось. Не двигайся дальше. Проверь подписку, вход в аккаунт и что команда установки прошла без ошибок. Если терминал пугает и ничего не заводится — вернись к дорожке A.

Шаг 0.1. Установи Super Puper Powers (SPP)

Super Puper Powers (SPP) — это набор рабочих инструкций для агента: сначала понять задачу и выбрать процесс, не писать код раньше времени, проверять результат. Подробно разберём в модуле 6. Сейчас задача проще: поставить SPP и проверить, что вход в процесс работает.

Если хочешь подробную инструкцию с ручной установкой, открой дополнительный материал Настройка Super Puper Powers. Здесь — короткий путь, чтобы пройти первую практику без археологии по документации.

Если у тебя уже стоит obra/superpowers — сначала сними его. SPP заменяет obra, держать оба вредно: у них скиллы с одинаковыми именами и они конфликтуют по триггерам.

Самый простой вариант — попросить агента установить SPP глобально:

Зайди в репозиторий tsergeytovarov/super-puper-powers.

Установи Super Puper Powers глобально для всех моих проектов в этом инструменте.

Перед установкой:
1. прочитай README и инструкцию установки;
2. проверь, какой инструмент сейчас используется: Codex App или Claude Code;
3. покажи команды, которые собираешься выполнить;
4. спроси подтверждение перед изменениями.

После установки:
1. проверь, что команда /spp доступна;
2. ничего не меняй в моих проектах;
3. верни короткий отчёт: что установлено, где лежит, как вызвать.

Установка зависит от дорожки.

Дорожка A (Codex App) — в терминале Codex:

codex plugin marketplace add tsergeytovarov/super-puper-powers
codex plugin add super-puper-powers@super-puper-powers

Дорожка B (Claude Code) — в Claude Code:

/plugin marketplace add tsergeytovarov/super-puper-powers
/plugin install super-puper-powers@super-puper-powers-marketplace

После установки открой новый чат или перезапусти инструмент, если он так требует, и проверь вход в процесс — одинаково для обеих дорожек:

/spp

Проверь, доступны ли SPP или skills в этом окружении.
Ничего не меняй в файлах.
Не начинай код.

В Claude Code оркестратор ещё и сам включается хуком в начале сессии, но /spp работает всегда. В Codex хука нет — зови /spp руками.

Успех: агент отвечает про доступные skills/workflow и не начинает писать приложение.

Если не получилось, не делай вид, что всё нормально. SPP ставится один раз и дальше экономит силы на каждом модуле, поэтому лучше починить установку сейчас. Совсем не заводится — запиши, что SPP пока не установлен, и вернись к установке в модуле 6.

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

SPP preflight

Теперь начинай рабочую сессию через /spp:

/spp

Мы на модуле 1. Нужно сформулировать первую гипотезу моего проекта и учебный черновик docs/discovery.md.

Задача:
- не писать код;
- выбрать подходящий workflow для формулирования гипотезы;
- помочь сузить пользователя, боль, сигнал успеха, preflight-ресерч и ограничения;
- вернуть вопросы, если данных не хватает.

Что записать в учебный черновик docs/discovery.md

В модулях 1–3 docs/discovery.md — это учебный черновик: заметка, чат или временный файл, где ты собираешь решения по продукту. Реальная папка проекта и файл jobtrack/docs/discovery.md появятся в модуле 4. Туда ты перенесёшь этот черновик.

Создай раздел Гипотеза MVP и заполни не только формулировку, но и первые проверки:

• Пользователь: конкретный первый сегмент.
• Боль: одно предложение без общих слов.
• Гипотеза: проверяемая формулировка MVP.
• Сигнал успеха: по какому поведению или результату понятно, что гипотеза сработала.
• Сегмент и контекст: для кого именно проверяется идея.
• Ресерч рынка: где запускался preflight-ресерч и какие альтернативы найдены.
• Ограничения: продуктовые, технические, юридические и платформенные риски.
• Первый безопасный MVP-шаг: как проверить гипотезу без лишнего риска.

Что проверить

1. Сегмент и контекст

Перед ресерчем зафиксируй, кого ты изучаешь. Не люди, которые ищут работу, а, например, активные IT-соискатели в России, которые откликаются на 10+ вакансий в неделю.

Проверь:

• роль или тип пользователя названы явно;
• география, рынок или канал не забыты;
• сценарий достаточно узкий, чтобы искать конкурентов и альтернативы.

2. Где запускался preflight-ресерч

Запусти короткое исследование минимум в 2 местах:

• ИИ с веб-поиском: ChatGPT, Claude или другой инструмент, который умеет искать актуальные источники;
• поисковик или research-инструмент: Google, Яндекс, Perplexity;
• сайты конкурентов, каталоги шаблонов, комьюнити и отзывы.

В учебный черновик docs/discovery.md запиши не только вывод, но и где ты искал. Иначе это не ресерч, а ощущение в красивой упаковке.

3. Конкуренты и альтернативы

Выпиши не только прямых конкурентов, но и ручные обходные решения.

Для JobTrack это могут быть:

• Google Sheets;
• Notion-шаблоны;
• Trello-доски;
• статусы внутри job-сайтов;
• заметки и сохранённые сообщения в Telegram.

Часто первый конкурент твоего продукта — не другой продукт, а таблица, заметка и 40 вкладок в браузере.

4. Юридические и платформенные ограничения

Отдельно проверь, можно ли собирать данные выбранным способом.

Если идея требует забирать вакансии с работных сайтов, не начинай с парсинга как с очевидного решения. Сначала выпиши вопросы:

• есть ли у площадки официальный API;
• что написано в условиях использования;
• разрешён ли автоматический сбор данных;
• какие данные могут считаться персональными;
• нужно ли согласие пользователя на импорт и хранение;
• есть ли риск блокировки аккаунта или IP.

Это не заменяет юриста. На этом этапе задача проще: понять, не строишь ли ты MVP на способе, который нельзя нормально использовать.

Запиши ограничения таблицей:

Источник данных	Что хотим брать	Что проверить	Риск	MVP-решение
Job-сайт	ссылку, название вакансии, статус отклика	API, условия использования, robots.txt, автоматический сбор	парсинг может быть запрещён, аккаунт могут заблокировать	начать с ручного добавления ссылки
Telegram	вакансии из каналов и личных сообщений	согласие пользователя, приватность переписок, способ импорта	можно случайно сохранить личные данные	начать с ручного копирования текста или ссылки
Таблица пользователя	старые вакансии и статусы	формат файла, состав персональных данных	импорт сломается на разных структурах таблиц	дать простой CSV-шаблон

5. Безопасный MVP-шаг

После ресерча выбери первый способ проверки, который не требует спорной интеграции.

Для JobTrack безопаснее начать с ручного добавления вакансии, импорта ссылки или простого browser-action, чем сразу строить фоновый сбор данных с job-сайтов.

Сначала ценность. Интеграции потом.

Шаблон

## Гипотеза MVP

Пользователь: активный IT-соискатель в России, который откликается на 10+ вакансий в неделю.

Боль: он теряет историю откликов и не понимает, что делать дальше по каждой вакансии.

Гипотеза: если JobTrack позволит быстро сохранять вакансию и видеть статус отклика, пользователь перестанет держать поиск работы в 40 вкладках.

Сигнал успеха: пользователь возвращается в список и обновляет статусы минимум несколько раз в неделю.

Сегмент и контекст: активный поиск работы, вакансии приходят из job-сайтов, Telegram и личных сообщений.

Ресерч рынка: проверены Google Sheets, Notion-шаблоны, Trello, статусы job-сайтов, специализированные трекеры откликов. Preflight-ресерч запускался в ИИ с веб-поиском и вручную проверялся через поисковик и сайты конкурентов.

Ограничения: главный продуктовый риск - ручное обновление статусов. Юридический и платформенный риск - сбор данных с job-сайтов: нужно проверить правила площадок, API, автоматический сбор, персональные данные и согласие пользователя.

Таблица ограничений:

| Источник данных | Что хотим брать | Что проверить | Риск | MVP-решение |
|---|---|---|---|---|
| Job-сайт | ссылка и описание вакансии | API, условия использования, robots.txt | нельзя собирать данные выбранным способом | ручное добавление ссылки |
| Telegram | текст вакансии из канала или сообщения | приватность, согласие пользователя | можно сохранить личные данные | ручное копирование |

Первый безопасный MVP-шаг: начать с ручного добавления вакансии или сохранения ссылки, не с фонового парсинга сайтов.