Health Onboarding — Discovery-интервью

Профиль. До чтения и записи определи активный профиль по .claude/shared/profile-resolution.md. Короткий путь Data/X в этом файле означает Data/profiles/<активный>/X — буквально по нему писать нельзя. Перед записью назови, в чей профиль она идёт.

Назначение

Первый запуск health-системы. Структурированное discovery-интервью для сбора всех медицинских данных и создания traction-плана по направлениям здоровья.

Повторный запуск

Первым делом — определить режим. Прочитать Data/profile.json и проверить содержательные массивы:

allergies[] непуст  ИЛИ  chronic_conditions[] непуст  ИЛИ  current_complaints[] непуст

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

1. Прочитать текущее состояние всех файлов
2. Показать статус заполнения:
   • ✅ Заполнено: [список]
   • ⚠️ Частично: [список]
   • ❌ Пусто: [список]
3. Предложить дополнить пробелы — точечно, по тем блокам, где данных нет
4. НЕ проводить полное интервью заново

basic.full_name индикатором не является. Оно может быть пустой строкой при полностью заполненной медкарте — пациент просто не назвал имя системе, которая ведёт данные только о нём. Гейт по full_name отправил бы скилл по ветке первого запуска и уничтожил бы данные, накопленные за месяцы.

Запрет на перезапись

Действует в обоих режимах:

• Существующие данные не перезаписывать без явного подтверждения пользователя. Новое значение поверх непустого поля — только после вопроса «в профиле уже записано X, заменить на Y?» и ответа «да»
• Массивы (allergies, chronic_conditions, current_complaints, medications, doctors) дополнять, а не пересоздавать. Запись целого массива поверх старого запрещена
• Поле version в каждом JSON сохранять как есть
• Если данные противоречат друг другу — не выбирать самому, показать оба варианта пользователю
• Сомневаешься, первый это запуск или повторный, — считать повторным. Цена лишнего вопроса ниже цены потерянной медкарты

Workflow первого запуска

Проводить интервью БЛОКАМИ. После каждого блока — сохранять данные в соответствующие файлы.

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

Блок 1. Базовый профиль (~5 мин)

Спросить:

1. Биологический пол — male / female / intersex. Спрашивать нейтрально и объяснить, зачем: «От этого зависят референсные интервалы анализов и то, какие обследования показаны по возрасту». Это не формальность — без пола часть выводов система построить не сможет
2. Группа крови (если знаешь)
3. Рост и текущий вес
4. Аллергии (лекарственные, пищевые, другие) — для каждой: аллерген, тип, тяжесть
5. Хронические заболевания (если есть) — что, с какого года, статус
6. Операции и госпитализации в прошлом
7. Семейный анамнез — основные заболевания у ближайших родственников

Про пол — три отдельных поля, не одно:

• basic.sex — биологический пол. Определяет референсы и скрининг
• basic.gender_identity — как человек себя идентифицирует, если это отличается от sex и он захотел сказать. Отдельным вопросом не спрашивать: заполняется, только если пользователь сам поднял тему. Влияет на обращение, не на медицину
• basic.hormone_therapy — заместительная терапия или гормональная контрацепция: тип, препараты, с какого года. Спросить, если человек упомянул. Сдвигает ожидаемые значения гормонов, картины крови и липидов

Если пользователь не хочет отвечать про пол — записать not_specified, не настаивать и предупредить, что часть анализа будет недоступна.

→ Сохранить в Data/profile.json (basic, allergies, chronic_conditions, family_history) → Сохранить в Data/history.json (операции, госпитализации)

Блок 2. Текущие проблемы и направления (~10 мин)

Прочитай Data/goals/YYYY.json → directions[]. Дальше две ветки.

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

Если массив пуст — так будет на первой установке, и это нормально. Направления не спрашиваются по списку, а собираются из ответов:

1. Задать открытый вопрос: «Что беспокоит по здоровью прямо сейчас? Перечисли всё, что приходит в голову — потом разложим по направлениям».

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

   общее самочувствие и энергия · сон · ЖКТ · сердце и давление · гормоны · почки и мочевыделение · нервная система и головные боли · опорно-двигательный аппарат · кожа · зубы · зрение · ЛОР · ментальное здоровье · репродуктивное здоровье

3. Из того, что человек назвал, сформировать directions[] — по одному направлению на область, где есть жалоба. Пустые области не заводить: направление без содержания только засоряет цели.

4. Присвоить kr последовательно (KR5.0, KR5.1, …), area — название области, status — not_started.

5. Записать в Data/goals/YYYY.json, где YYYY — текущий год.

Для каждого направления — по одной схеме:

• что беспокоит, когда началось, был ли у врача, диагноз, текущее лечение

Формулировку адаптировать под area: для «Стоматология» — «что нужно лечить, был ли у стоматолога, есть ли план», для «Гормоны» — «проверялся ли, есть ли жалобы», для «Ментальное здоровье» — мягче и без давления.

Если направление пациента не беспокоит — пометить и идти дальше, не выспрашивать.

В конце — открытый вопрос: «Есть ли что-то ещё, что беспокоит и не попало в список?» Новую жалобу записать даже если она не ложится ни в одно из направлений.

→ Обновить Data/profile.json → current_complaints[] → Для каждой жалобы: { "area": "", "description": "", "since": "", "status": "investigating" }

Блок 3. Врачи (~3 мин)

Спросить:

• У каких врачей наблюдаешься?
• Для каждого: ФИО, специальность, клиника, контакт (если есть)
• Когда был последний визит к каждому?

→ Сохранить в Data/doctors/contacts.json

Полная схема — .claude/shared/data-schemas.md. Реальный формат файла: обёртка {version, doctors[]}, запись добавляется в массив doctors[], поле version не трогается.

{
  "name": "",
  "specialty": "",
  "clinic": "",
  "period": "",
  "status": "active",
  "phone": ""
}

Важно: поля id у врачей нет — ссылки строятся по составному ключу «имя + специальность». Полей email и last_visit в схеме тоже нет, не выдумывать их. Допустимые статусы: active, historical, rejected.

Блок 4. Лекарства и БАДы (~3 мин)

Спросить:

• Что сейчас принимаешь? (название, дозировка, частота, время приёма)
• Кто назначил?
• БАДы / витамины?

→ Сохранить в Data/medications/current.json

Полная схема — .claude/shared/data-schemas.md. В файле четыре массива, и запись кладётся в тот, которому соответствует:

Массив	Что туда	Префикс id
medications[]	Рецептурные и безрецептурные лекарства	med_
supplements[]	БАДы и витамины	sup_
topical[]	Наружные средства: кремы, мази, капли	top_
protocols[]	Схемы лечения из нескольких компонентов	prot_

// medications[]
{ "id": "med_01", "name": "", "dosage": "", "frequency": "", "timing": ["утро"],
  "with_food": true, "reason": "", "doctor_id": null, "started": "", "until": null,
  "side_effects": [], "status": "active", "notes": "" }

// supplements[]
{ "id": "sup_01", "name": "", "brand": "", "dosage": "", "frequency": "",
  "timing": ["утро"], "reason": "", "started": "", "status": "active" }

// topical[]
{ "id": "top_01", "name": "", "type": "", "frequency": "", "reason": "", "status": "active" }

Важно: id инкрементальный в пределах своего массива, с ведущим нулём до двух знаков. Перед записью нового препарата — сверить с Data/profile.json → allergies[] на предмет противопоказаний.

Блок 5. Анализы (~2 мин)

Спросить:

• Есть ли результаты анализов на руках? (PDF, фото, бумажные)
• Когда сдавал последний раз?
• Какие типы анализов есть?

→ НЕ создавать записи — составить чеклист документов для последующей загрузки → Вывести: «Положи файлы (PDF, сканы, фото) в каталог Inbox/ и запусти /inbox — он разберёт их и разложит по Data/»

Inbox/ + /inbox — единственная точка входа для файлов. /labs работает с уже оцифрованными результатами: расшифровка, тренды, ручной ввод. PDF в /labs не передавать.

Блок 6. Стоматология (~2 мин)

Спросить:

• Общее состояние зубов (своими словами)
• Что лечили / удаляли / ставили (коронки, импланты, пломбы)
• Есть ли план лечения от стоматолога?
• Когда последний раз был у стоматолога?

→ Заполнить Data/dental/tooth-map.json — по возможности (номера зубов по ISO 3950) → Заполнить Data/dental/procedures.json — известные процедуры

Блок 7. Прививки (~1 мин)

Спросить:

• Какие прививки помнишь? (COVID, грипп, другие)
• Есть ли сертификат вакцинации?

→ Заполнить Data/vaccinations.json

Блок 8. Fitness и метрики тела (~2 мин)

Спросить:

• Текущий вес (если не сказал в блоке 1), целевой вес
• Тренировки: тип, частота, где занимаешься

WHOOP — это MCP-сервер (.mcp.json), а не агент. Если сервер подключён — подтянуть последние метрики его инструментами. Если MCP недоступен (сервер не поднят, нет авторизации, инструменты не отвечают) — не блокировать блок: записать данные со слов пользователя, пометить «WHOOP не подключён — метрики восстановления не собраны» и продолжить.

→ Первая запись в Data/body-metrics.csv → Обновить Data/goals/YYYY.json → fitness_target

Блок 9. Ментальное здоровье (~2 мин)

Спросить:

• Общий уровень стресса (1–10)
• Качество сна субъективно (1–10)
• Есть ли тревожность / выгорание
• Ходишь ли к психологу

→ Первая запись в Data/mental/journal.jsonl:

{"ts":"<текущие дата и время в ISO 8601 с офсетом +03:00>","mood":0,"energy":0,"stress":0,"sleep_quality":0,"notes":"onboarding — первичная оценка","tags":["onboarding"]}

Значение ts брать из системного времени (date +"%Y-%m-%dT%H:%M:%S%z"), числовые поля — из ответов пользователя. Плейсхолдеры в файл не писать: строка вида 2026-XX-XXTXX:XX:XX невалидна и ломает разбор JSONL.

Блок 9a. Репродуктивное здоровье (~3 мин, зависит от пола)

Состав вопросов определяется полем basic.sex. Тема чувствительная: спрашивать нейтрально, без оценок, любой вопрос можно пропустить. Если человек не хочет отвечать — записать в _needs_input[] и идти дальше.

Объяснить, зачем спрашиваешь: «Это тот же уровень контекста, что питание и сон. Без него система будет искать редкие причины там, где объяснение на поверхности».

Если sex = female:

1. Цикл: регулярный или нет, длительность, дата последней менструации
2. Объём кровопотери: обильные менструации или обычные. Вопрос обязателен — это самая частая причина дефицита железа, и без него система пойдёт искать источник в ЖКТ
3. Болезненность менструаций, влияние на работоспособность
4. Беременности и роды в анамнезе
5. Контрацепция: тип, с какого года
6. Менопаузальный статус, если по возрасту актуально: приливы, изменения цикла
7. Когда последний раз были цитология шейки матки, ВПЧ-тест, УЗИ малого таза, маммография

Если sex = male:

1. Мочеиспускание: частота, ночные подъёмы, напор струи
2. Была ли когда-нибудь сдача ПСА, когда
3. Жалобы по репродуктивной части, если есть

Если sex = intersex либо not_specified: спросить, какие органы присутствуют, и от этого выстроить набор вопросов. Скрининг определяется наличием органа, а не идентичностью.

→ Записать в Data/profile.json → блок reproductive:

// для female
{ "cycle_regular": null, "cycle_length_days": null, "last_period": null,
  "flow": null, "dysmenorrhea": null, "pregnancies": null, "births": null,
  "contraception": null, "menopause_status": null,
  "last_cervical_screening": null, "last_mammography": null, "_needs_input": [] }

// для male
{ "urinary_symptoms": null, "last_psa": null, "notes": null, "_needs_input": [] }

Правила:

• Обильные менструации — не «особенность», а состояние, влияющее на обмен железа. Зафиксировать факт, не давая оценок
• Пропущенный скрининг отметить как пробел, но не давить и не пугать
• Не задавать вопросов, не следующих из sex. Мужчине не нужен вопрос про цикл, женщине — про простату

Блок 10. Контекст жизни и среды (~7 мин)

Обязательный блок. На этих данных построена холистическая рамка (.claude/shared/holistic-framework.md), которой пользуются все 13 AI-специалистов и консилиум. Без них специалисты работают вслепую и уходят искать редкие причины там, где ответ в образе жизни.

10a. Привычки и поведение → Data/profile.json → lifestyle

Спросить:

• Питание: считаешь ли калории, текущая фаза (дефицит / поддержание / профицит), типичный приём пищи, история веса
• Вода: сколько литров в сутки
• Кофеин: сколько кофе, чая, энергетиков в день и во сколько последний приём
• Алкоголь: как часто, сколько
• Никотин: сигареты, вейп, кальян, жевательный — что и как часто
• Сон: во сколько ложишься и встаёшь в будни, во сколько в выходные, сколько часов выходит, при какой длительности страдаешь
• Экраны и свет: экранное время в день, во сколько выключаешь экраны вечером, сколько дневного света утром
• Тренировки: тип, частота, где занимаешься
• Работа: сфера, сидячая или нет

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

→ Записать в Data/profile.json → lifestyle: подобъекты nutrition, hydration, caffeine, alcohol, smoking, sleep, sleep_regularity, screen_and_light, exercise, work → Всё, на что пользователь не ответил, перечислить в lifestyle._needs_input[] строкой «поле — что именно спросить и почему это важно»

10b. Среда и обстоятельства → Data/context/environment.json

Спросить:

• География: город, район, ближайшее метро, с какого года здесь живёшь, где жил раньше
• Медицина: ОМС, ДМС (если есть — какой), готовность ездить, предельное время в пути
• Жильё: тип, этаж, увлажнитель или очиститель воздуха, сырость и плесень, животные, темнота и тишина в спальне, температура
• Работа и нагрузка: удалёнка или офис, график, часов у экрана, когнитивная нагрузка, давление дедлайнов, дорога до работы
• Циркадные: утренний свет, экраны вечером, время на улице, сменный график, перелёты со сменой часовых поясов
• Стресс и опора: основные стрессоры, финансовый и рабочий стресс, есть ли на кого опереться, значимые события за последний год
• Хронологические якоря: переезды, смены работы, потери, операции, длительные болезни — с датами. Нужны, чтобы соотносить начало симптомов с событиями жизни

→ Записать в Data/context/environment.json: location, healthcare_access, housing, work, circadian_context, stress_context (в него — chronology_anchors), обновить updated → climate заполнить производно от location: широта, длина светового дня, отопительный сезон, перепады давления. Это выводится из географии, спрашивать не нужно → air_and_water — качество воздуха, близость к шоссе, источник и жёсткость воды → Незаполненное — в _needs_input[]

Оба файла заполняются частично — это нормально. Пустое поле, честно помеченное в _needs_input, лучше выдуманного значения. Ничего не додумывать за пользователя.

Блок 11. Цели и traction-план (~3 мин)

1. Показать текущие KR из O5 и собранные данные
2. Спросить: «Всё верно? Что скорректировать?»
3. Установить приоритеты: что лечить первым?
4. Ближайшие шаги (next actions) по каждому направлению

→ Обновить Data/goals/YYYY.json — goal, next_action, deadline для каждого направления → Обновить Goals/health-goals.md → Создать задачи в Todoist (follow-up визиты, анализы) — через MCP todoist add-tasks → Создать события в Google Calendar (если есть конкретные даты)

Финал

После всех блоков:

1. Сводка — что заполнено, что нужно донести:

   ✅ Профиль заполнен
   ✅ 3 врача добавлены
   ✅ 2 препарата зафиксированы
   ✅ Контекст жизни и среды собран (пробелы: caffeine, housing)
   ⚠️ Анализы: положи PDF в Inbox/ и запусти /inbox
   ⚠️ Зубы: уточни номера при следующем визите
   

2. Traction-таблица — строки по всем направлениям из Data/goals/YYYY.json → directions[], а не по фиксированному списку:

   | Направление | Статус | Следующий шаг | Дедлайн |
   |-------------|--------|---------------|---------|
   | [area из directions[0]] | — | — | — |
   | [area из directions[1]] | — | — | — |
   | ... | | | |
   

   Строк столько, сколько направлений в файле.

3. Про сохранение данных. Коммитить содержимое Data/ не нужно и не получится: каталог целиком закрыт .gitignore. Это предохранитель — так случайно опубликовать свою медкарту невозможно, даже выполнив git add -A.

   Сказать об этом пользователю прямо, одной фразой: «Данные записаны в файлы на твоём диске. Под контроль версий они намеренно не попадают — так их нельзя случайно опубликовать. Резервная копия — это твоя копия каталога, а не git».

   Если в ходе онбординга изменились файлы вне Data/ — например MEMORY.md, — их можно закоммитить обычным порядком, показав список через git status --short и спросив подтверждение. Push не делать: у проекта нет remote по построению.

4. Передать эстафету в ритм работы. Онбординг — разовое событие, дальше система живёт короткими касаниями. Не обрывать разговор на коммите: человек только что заполнил медкарту и не знает, что делать завтра. Показать ритм явно:

   Медкарта заведена. Дальше система работает так:
   
     Начало сессии   /day        — что изменилось, что требует внимания
     В процессе      по задаче   — /labs, /doctor, /body, /mental, /inbox
     Конец сессии    /wrap-up    — сохранит контекст, обновит память, сделает коммит
   
   /wrap-up — единственный способ не потерять наработанное между сессиями.
   Он пишет лог, обновляет активный контекст и фиксирует изменения в git.
   Без него следующая сессия начнётся почти с чистого листа.
   
   Ближайший шаг: положи PDF анализов в Inbox/ и запусти /inbox.
   Дальше по этапам — docs/ONBOARDING.md
   

   Если остались незаполненные блоки — назвать их здесь же и сказать, что вернуться можно в любой момент: /profile для точечной правки либо повторный /onboarding, который войдёт в режим дополнения и не будет переспрашивать пройденное.

Пауза и возобновление

Интервью длинное и многошаговое, прерывание — штатная ситуация. Прогресс держать в Cache/checkpoint.yml (см. .claude/rules/active-context.md).

В начале интервью записать:

active: true
task_id: "onboarding-YYYY-MM-DD"
task_title: "Health onboarding — discovery-интервью"
skill: "onboarding"
current_step: "block_1"
total_steps: 11
started_at: "<ISO 8601 из системного времени>"
last_updated: "<ISO 8601 из системного времени>"
context:
  blocks_done: []
  blocks_remaining: ["block_1", ..., "block_11"]
  notes: ""

После каждого блока обновлять current_step, blocks_done, blocks_remaining, last_updated.

При просьбе о паузе — сохранить данные текущего блока, обновить checkpoint, назвать пользователю, на чём остановились и чем продолжить:

Остановились на блоке N из 11 ([название]).
Продолжить: /onboarding — подхватит с этого места.

При возобновлении — прочитать Cache/checkpoint.yml; если active: true и skill: onboarding, начать с current_step, а не сначала. Пройденные блоки не переспрашивать.

После блока 11 — active: false, поля обнулить.

Правила

• Вопросы задавать БЛОКАМИ, не все сразу
• После каждого блока — подтверждение «Всё верно? Идём дальше?»
• Если пользователь не знает ответ — пропустить, пометить как пробел в _needs_input[]. Не додумывать значения
• Существующие данные не перезаписывать без явного подтверждения — см. «Запрет на перезапись» выше
• Списки направлений и специалистов читать из данных (Data/goals/YYYY.json), не хардкодить
• Файлы (PDF, сканы, фото) — только через Inbox/ + /inbox. Не через /labs
• Disclaimer при сборе данных: «Эти данные хранятся локально и в git. Решения о лечении — только с врачом.»
• Не торопить — тайминги блоков ориентировочные, при просьбе о паузе фиксировать прогресс в checkpoint
• Медданные не покидают каталог проекта — запись PHI куда-либо вовне запрещена. Наружу, если это вообще нужно, идут только агрегаты: количества, статусы, метрики. Никаких названий препаратов, диагнозов, аллергенов, ФИО и дат рождения

Критерий завершения: режим (первый запуск / дополнение) определён по содержательным массивам профиля; пройдены все 11 блоков либо явно помечены пропущенные; Data/profile.json (включая lifestyle) и Data/context/environment.json записаны, незаполненное перечислено в _needs_input[]; ни одно непустое поле не перезаписано без подтверждения пользователя; traction-таблица покрывает все направления из directions[]; Cache/checkpoint.yml деактивирован; коммит сделан после показа списка файлов и согласия пользователя; пользователю показан ритм дальнейшей работы (/day → задачи → /wrap-up) и назван ближайший шаг.