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

Критерии готовности

Зачем нужно​

Документ фиксирует проверяемые критерии, по которым identity-домен считается достаточно описанным и реализуемым с нуля.

Документация готова, если​

  • описаны границы домена и соседние владельцы;
  • описана каноническая модель данных;
  • описана точная схема БД с DDL, индексами, FK, unique constraints и retention;
  • описаны статусные модели ключевых сущностей;
  • описаны основные пользовательские, админские и системные сценарии;
  • описана карта API;
  • описаны API-контракты, DTO, validation и error codes;
  • описаны параметры безопасности;
  • описана матрица прав;
  • описаны OAuth/OIDC contracts;
  • описаны RBAC и permissions;
  • описаны family и organization contexts;
  • описан educator_profile как анкета без прав;
  • описана граница с Learning Workspace, learning_group и learning_group_participant;
  • описаны audit, events, notifications, transports и logging;
  • описаны frontend-core, UI Kit, admin и platform settings;
  • есть правила безопасности и нестандартные случаи.
  • описаны экраны и тестовая матрица.

Серверная часть готова, если​

  • реализованы users, contacts, credentials и auth methods;
  • реализована регистрация, login, reset password, verification и logout;
  • refresh token rotation защищает от повторного использования старого token;
  • sessions можно просматривать и отзывать;
  • RBAC проверяется на сервере для каждого admin/domain endpoint;
  • family delegated sessions передают actor context;
  • child device authorization создаёт сессию linked user ребёнка и не подменяет adult actor context;
  • родительский режим не подменяет детский режим;
  • linked user ребёнка в MVP сохраняет self-права;
  • взрослый не получает доступ к учебному контуру другого взрослого;
  • educator_profile создаётся и проверяется без выдачи глобальной роли teacher;
  • organization/team memberships имеют scope-aware permissions;
  • organization reference search работает и не выдаёт прав;
  • пользователь может создать organization или request membership;
  • unclaimed organization can be claimed only after system admin approval;
  • owner can invite members and transfer ownership;
  • organization students can be created, deduplicated and archived;
  • organization_student ограничен официальным организационным контуром и не используется как список всех рабочих учеников преподавателя;
  • самозаявленный преподаватель может создавать свои рабочие группы только через flows, принадлежащие LMS, и не может читать чужие группы или официальную статистику;
  • system admin can merge duplicate organizations after impact preview;
  • all significant organization actions are audited;
  • competitions может использовать organization_student как external ref;
  • task-bank can use organization/team grants for access;
  • org RBAC acceptance covers owner/admin/member/team lead and audited global break-glass access;
  • OAuth/OIDC поддерживает Discovery, JWKS, Authorization Code + PKCE, token, userinfo, introspection и revocation;
  • plugins запускаются через sandbox и lifecycle service;
  • notification rules и transports работают через явные контракты;
  • audit logs пишутся для security/business actions;
  • application/access/audit/frontend logs разделены;
  • OpenAPI отражает публичные и admin endpoints.
  • database constraints соответствуют database-schema.md.

Фронтенд готов, если​

  • есть auth flow UI со всеми состояниями;
  • есть регистрация, вход, восстановление пароля и verification;
  • есть saved accounts и logout;
  • есть профиль пользователя и редактирование контактов;
  • есть страница безопасности: sessions, devices, password, MFA/auth methods, activity;
  • есть family UI;
  • есть organization UI;
  • есть UI для educator_profile без обещания прав;
  • есть notification center и настройки уведомлений;
  • есть admin dashboard;
  • есть управление users, roles, organizations, OAuth clients, plugins, settings;
  • UI скрывает недоступные действия, но не заменяет серверные проверки;
  • все формы имеют loading, empty, error и success states.
  • экраны соответствуют screen-spec.md.

Security готова, если​

  • password policy описана и enforced;
  • secrets не пишутся в логи;
  • verification codes хранятся как hash;
  • JWT подписываются безопасным алгоритмом;
  • refresh tokens хранятся как hash;
  • OAuth redirect URIs строго валидируются;
  • PKCE обязателен для public clients;
  • rate limits есть на auth, OTP, reset password, OAuth, invitations и admin-danger actions;
  • brute-force защита блокирует подозрительные попытки;
  • audit покрывает роли, security settings, plugins, OAuth clients, login failures и session revocation;
  • audit покрывает trust review educator_profile, делегированный детский режим и изменения organization access;
  • PII отдаётся только по scope/permission;
  • plugin sandbox не даёт читать чужие secrets и файловую систему вне разрешений.
  • значения лимитов и TTL соответствуют security-parameters.md.

Интеграции готовы, если​

  • LMS, CRM, storefront, competitions, management и task-bank используют identity через описанные contracts;
  • LMS получает user, educator_profile и scopes, но владеет Learning Workspace и learning_group_participant;
  • competitions использует organization_student только как официальный organization external ref, а не как список учеников каждого преподавателя;
  • OAuth clients имеют scopes и redirect URIs;
  • events идемпотентны и не содержат секретов;
  • downstream services могут проверить token или получить JWKS;
  • блокировка пользователя или отзыв роли отражаются в downstream доступе;
  • transport failures не ломают auth flow без понятного fallback.

Data готова, если​

  • все таблицы имеют migrations;
  • есть seed системных roles и permissions;
  • есть seed базовых system settings и navigation;
  • есть индексы на email, phone, session, role assignment, OAuth client, authorization code;
  • есть unique constraints, которые предотвращают дубли контактов и external identities;
  • есть retention policy для sessions, verification codes, audit logs и event logs;
  • есть redaction policy для PII.
  • схема проходит migration tests.

Нестандартные случаи покрыты, если​

  • повторный refresh token отзывает token family;
  • пользователь заблокирован во время активной сессии;
  • роль отозвана во время открытой админки;
  • invitation просрочен или уже принят;
  • provider возвращает конфликтующий email;
  • transport не доставил OTP;
  • plugin падает при обработке event;
  • family membership изменён администратором во время delegated session;
  • запрос child device authorization просрочен, отозван или уже completed;
  • родитель зарегистрировал ребёнка на олимпиаду, но пытается проходить её из родительского режима;
  • самозаявленный преподаватель указал организацию, но не получил membership/grant;
  • organization membership изменён во время OAuth session;
  • OAuth code повторно использован.

Готовность к разработке с нуля​

Identity можно отдавать в разработку, если разработчик или AI-агент может по документам:

  • создать схему базы;
  • реализовать auth flow;
  • реализовать RBAC и guards;
  • собрать API Gateway;
  • собрать пользовательский кабинет и админку;
  • подключить OAuth/OIDC clients;
  • подключить notifications/transports/events/logging;
  • написать тесты на happy path и security edge cases;
  • выполнить test-plan.md;
  • объяснить, какие данные identity не должен хранить.