ADR-022. Взрослый видит детей семьи

Контекст

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

MVP должен поддержать уже существующие аккаунты, где взрослые и дети могли пользоваться платформой без семейной группы. Поэтому family model не должна превращать linked child user в урезанный аккаунт по умолчанию.

Решение

family_group объединяет взрослых пользователей и детские student_profile.

• В семье может быть несколько взрослых и несколько детей.
• Любой active adult семьи видит и управляет всеми student_profile этой семьи.
• Adult не видит прогресс, календарь, профиль, уведомления, покупки и учебный контур других adults.
• Adult user может быть самостоятельным учащимся, покупать продукты для себя и иметь собственный прогресс, календарь и enrollments.
• student_profile является каноническим учебным subject ребёнка.
• Linked user ребёнка сохраняет собственные права пользователя в MVP: учиться, смотреть свой прогресс и календарь, редактировать свои данные, покупать продукт себе и действовать под своим аккаунтом.
• Семейная группа добавляет взрослым права над детьми, но не ограничивает ребёнка.
• Родительский режим — adult действует от своего имени по отношению к student_profile.
• Delegated session — adult входит в детский контекст, но sub остаётся adult user, а audit хранит adult actor и child subject.
• Авторизация ребёнка на устройстве реализуется через child_device_authorization и не является delegated session.
• Для student_profile без linked_user_id device authorization в MVP невозможна без предварительного создания или привязки user.

Покупки и назначения продуктов

Семейный доступ не означает, что покупатель и учащийся совпадают. CRM и billing должны разделять покупателя, плательщика, получателя продукта и учебного субъекта.

Взрослый может купить продукт для ребёнка, ребёнок с linked user может купить продукт себе, а будущие семейные продукты могут назначаться на family_group.

Календарь и прогресс

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

Последствия

• Нельзя строить MVP на модели “ребёнок всегда ограничен взрослыми”.
• Нельзя использовать service access gating как скрытую per-adult модель доступа к детям, если правило adult → all children остаётся каноническим.
• Self-service удаление семьи, выход взрослого, удаление взрослого участника, перенос ребёнка и конфликтная отвязка ребёнка не входят в пользовательский MVP; редкие операции выполняются администраторами вручную.
• LMS должен принимать family adult context для чтения календаря и прогресса ребёнка, но остаётся владельцем учебных данных.
• CRM и billing должны принимать family context, но не считать, что purchaser = beneficiary = enrollment subject.
• Platform notifications владеет правилами, каналами и шаблонами уведомлений; Family Group поставляет family context и проверку получателей.
• Audit фиксирует delegated session отдельно от обычной сессии и отличает её от child device authorization.

Связи

• relates: ADR-016, ADR-017, ADR-018, ADR-036