Спецификация приложения для проверки условий ВНЖ

Выполни задачу ниже и строго соблюдай все обязательные требования.

Ты — продуктовый дизайнер и технический аналитик, задача — подготовить детальное, самодостаточное техническое задание (spec) и структурированную спецификацию данных для разработки веб/мобильного приложения для потенциальных экспатов. Приложение должно определять требования для получения долгосрочного вида на жительство в указанном пункте назначения и предоставлять подробную, легко усвояемую информацию о визах, требованиях к доходу, медицинском страховании, проверках на отсутствие судимостей и прочих релевантных требованиях. Не давай юридических советов — всегда включай явный дисклеймер, что информация носит справочный характер и должна быть проверена через официальные источники.

Входные данные (что вводит пользователь):
- желаемая страна (обязательное), опционально — город/регион;
- гражданство пользователя (обязательное);
- цель переезда (категории: работа, учеба, воссоединение семьи, инвестиции, пенсионный переезд, другое) (обязательное);
- предполагаемая продолжительность пребывания (месяцы/годы);
- источник дохода/тип занятости (наёмный, фриланс/удалённая работа, собственный бизнес, пассивный доход, пенсионер, инвестор);
- примерный годовой/ежемесячный доход в местной или базе валюте;
- наличие сопровождающих членов семьи (есть/нет) и их статус (партнёр, дети, пожилые родственники);
- данные о здоровье/необходимом медстраховании (обычно булевы флаги: хронические состояния, требуется ли покрытие для уже существующих заболеваний — необязательно вводить подробности);
- сведения о судимостях (булево: есть/нет; если есть — поле с текстом, но помни о приватности);
- язык интерфейса (предпочтительный язык вывода);
- необязательно: готовность переехать временно/постоянно, требование к цене жизни/налогообложению.

Требуемые результирующие блоки и формат вывода
- Ответ должен быть представлен в виде одного JSON-объекта верхнего уровня с ключами:
  - product_overview: краткое (3–6 предложений) описание приложения и целевой аудитории (русский).
  - user_input_spec: список полей ввода с типами, примерами и правилами валидации.
  - functional_requirements: нумерованный перечень функций (по приоритету) — что приложение делает (по крайней мере: определение требований по выбранной стране, детальная карточка требований, источники и ссылки, пояснения по потенциальным исключениям/искам, генерация персонализированного чек-листа, сохранение профиля пользователя, экспорт/печать, уведомления об изменениях).
  - nonfunctional_requirements: краткие требования к безопасности, масштабируемости, времени отклика, поддерживаемым платформам.
  - data_model: схемы (JSON Schema) для основных сущностей: CountryRule, VisaType, IncomeRequirement, InsuranceRequirement, CriminalCheckRequirement, UserProfile, SearchResult. Для каждой схемы укажи обязательные поля, типы и примеры значений.
  - api_spec: минимум 4 REST API endpoint'а (маршруты, методы, входные параметры, пример запроса и пример ответа) для: поиска страны, получения карточки требований по стране+категории, сохранения профиля пользователя, подписки на обновления правил.
  - data_sources: список рекомендуемых типов источников (официальные правительственные сайты, консульства, миграционные службы, международные организации), требования к валидации данных, частота обновления данных и стратегия кэширования/версионирования правил.
  - ui_wireframes_text: текстовое описание 3 основных экранов (по умолчанию: экран поиска/ввода, экран результатов/карточка требований, экран персонализированного чек-листа). Для каждого экрана приведи структуру элементов (заголовки, поля, кнопки, важные подсказки/предупреждения) и пример текстов подсказок/дисклеймеров.
  - personalization_logic: правило/алгоритм, как на основе входных данных формируется персонализированный набор требований (описать шаги фильтрации/приоритезации и минимальные проверки непротиворечивости).
  - privacy_and_compliance: минимальные требования по защите PII (шифрование в покое и при передаче, права пользователя на удаление данных), указания по соответствию GDPR/локальным законам (общие рекомендации), и текст краткого пользовательского соглашения/дисклеймера (русский).
  - testing_and_acceptance_criteria: 8–12 конкретных критериев и минимум 5 тест-кейсов (включая граничные случаи: конфликт дохода, несовпадение гражданства, наличие судимости).
  - implementation_timeline: разбивка по этапам (MVP — минимально жизнеспособный продукт, последующие итерации), с ориентировочными оценками человеко-часов для каждой фазы.
  - sample_response_examples: минимум 2 примерных JSON-ответа от API "карточки требований" для вымышленных/обобщённых сценариев (не указывай реальные юридические нормы — используй placeholders и явно пометь их как примеры). Каждый пример должен содержать: visa_types (список), income_minimums (структура), insurance_requirements (структура), criminal_check (структура), required_documents (список), approximate_processing_time, sources (список ссылок).
  - limitations_and_risks: короткий перечень потенциальных рисков (включая риск устаревших правил, региональные исключения, неправильный ввод пользователем) и способы их смягчения.

Ограничения и правила качества
- Ответ должен быть на русском языке.
- Не указывай конкретные, неподтверждённые юридические требования для реальных стран — вместо этого используй структурированные шаблоны и помечай реальные данные как "требуется подтвердждение из источника X".
- Все URL в разделе data_sources должны быть реальными доменами (например gov.xx), если указываешь примеры — пометь их как рекомендованные категории, а не как исчерпывающие.
- Формат кода/JSON должен быть корректным и валидируемым (проверь синтаксис).
- Дисклеймер (текст для UI) должен быть кратким (1–2 предложения) и включать фразу: "информация носит справочный характер и не заменяет консультацию с официальными миграционными органами или юристом".
- Приложение должно предусматривать хранение источника и даты последнего обновления для каждой записи о правиле.
- Учти приватность: если поле ввода содержит чувствительные данные (сведения о судимостях, здоровье), предложи минимизацию хранения (хранить только хэш/флаг и дату ввода) и явное согласие пользователя.

Тон и стиль
- Ясно, формально, без маркетинговых оборотов. В тексте спецификаций используй терминологию разработчиков и продукт-менеджеров (endpoint, schema, field, required/optional).

Не задавай уточняющих вопросов — выдай полную спецификацию в одном ответе в соответствии с вышеуказанным JSON-форматом.