diagnostics

name	diagnostics
description	Диагностика пробелов в компетенциях ученика через наблюдение за его рассуждением и артефактами. Триггерься, когда ученик решает задачу предметной области, объясняет своё решение, выбирает подход, обосновывает выбор. А также на сигналы пробелов — действует «на автопилоте» без обоснования, пропускает обязательный шаг, не проверяет себя. Реализует Bayesian Knowledge Tracing (BKT) для набора компетенций области. Обновляет progress/competencies.json. Работает stealth — ученик видит не диагноз, а его последствия (наводящие вопросы, микроуроки).
user-invocable	false

Диагностика компетенций предметной области

В областях, где нет автоматического оракула (компилятора, тестов, «зелёного прогона»), единственный наблюдаемый сигнал — как ученик рассуждает: какие вопросы задаёт, что проверяет, что выбирает и как обосновывает. Этот скилл диагностирует пробелы через think-aloud ученика и его артефакты (решения, расчёты, выбор подхода, готовый результат).

Это stealth assessment (Shute & Ventura 2013): ученик не сдаёт экзамен на знание. Он работает над задачей, а система в фоне диагностирует и адаптируется.

Компетенции под наблюдением

Ключи живут в progress/competencies.json. Состав набора зависит от области — он приходит из доменного слоя (см. <domain>-competencies поверх этого движка). Сам движок BKT универсален; меняется только список того, ЧТО наблюдаем.

Как определить компетенции области

Компетенция, пригодная для BKT-диагностики, — это наблюдаемый через рассуждение или артефакт навык, а не теоретический факт. Критерии хорошей компетенции:

1. Наблюдаема в работе. Видно по тому, как ученик решает задачу, а не по тому, может ли он процитировать определение. («Уточняет требования до решения» — да. «Знает определение термина X» — нет, это spaced_review.)
2. Бинарно засчитываема за эпизод. В каждом конкретном случае можно сказать «проявил / не проявил».
3. Повторяется across задач. Один и тот же навык всплывает в разных задачах области — иначе нечего трекать по интервалам.
4. Различает уровни. Junior и senior проявляют её по-разному (полезно как маркер уровня).

Чтобы вывести набор для новой области: возьми рубрику оценки работы в этой области (чек-лист ревью, критерии интервью, definition-of-done) → выпиши повторяющиеся навыки → отбрось чисто-фактические (они в spaced_review) → оставь те, что наблюдаемы в рассуждении/артефакте. Обычно получается 6–10 компетенций. Одну из них стоит назначить главным маркером уровня — навык, который сильнее всего отличает новичка от опытного (как правило это «сам ведёт процесс / проактивность», а не отдельный технический приём).

Пример набора (9 компетенций) для одной из областей:

Ключ	Что это	Сигналы пробела
requirements_clarification	Уточнение требований до начала работы	Сразу бросается решать, не уточнив рамки/входные данные
estimation_skill	Прикидочные расчёты «на салфетке»	Решает без оценки величин; «давай просто с запасом»
knowledge_of_components	Знание строительных блоков области	Не знает, когда какой блок применить; путает их роли
tradeoff_reasoning	Рассуждение о компромиссах	Находит развилку, но не выбирает/не обосновывает; «возьмём X» без «почему»
scalability_thinking	Мышление о росте/пределах	Не находит узкое место; не думает «что сломается при росте»
failure_thinking	Мышление об отказах/ошибках	Игнорирует сбойные сценарии; нет запаса прочности
data_modeling	Выбор модели под задачу	Берёт инструмент без связи с характером задачи
communication_thinkaloud	Вербализация рассуждения	Молча делает; не объясняет «почему здесь это»
proactiveness_driving	Ведёт процесс сам	Ждёт вопросов; не поднимает важные аспекты сам

Здесь proactiveness_driving — главный маркер уровня.

Формат файла

{
  "<competency_key_1>": {"p_known": 0.3, "observations": 0},
  "<competency_key_2>": {"p_known": 0.2, "observations": 0},
  "<competency_key_3>": {"p_known": 0.25, "observations": 0}
}

Стартовые значения подстраиваются под профиль и уровень из profile.json на онбординге: level: practicing → выше старт; level: zero → ниже. Для overconfidence-профилей (см. onboarding/references/profiles.md) помни: «я понял» НЕ повод поднимать p_known, нужно наблюдение в работе.

Bayesian Knowledge Tracing (Corbett & Anderson 1994)

Параметры: P_T=0.15 (научился), P_G=0.15 (угадал), P_S=0.08 (ошибся, хотя знает).

Наблюдение: применил компетенцию корректно

P_correct_if_known = 1 - P_S
P_correct_if_unknown = P_G
P_observed = p_known*P_correct_if_known + (1-p_known)*P_correct_if_unknown
p_known_updated = (p_known*P_correct_if_known) / P_observed
p_known_new = p_known_updated + (1 - p_known_updated) * P_T

Наблюдение: не применил / применил неверно

P_wrong_if_known = P_S
P_wrong_if_unknown = 1 - P_G
P_observed = p_known*P_wrong_if_known + (1-p_known)*P_wrong_if_unknown
p_known_updated = (p_known*P_wrong_if_known) / P_observed
p_known_new = p_known_updated + (1 - p_known_updated) * P_T * 0.5

BKT — не точная наука. Цель — тенденция, не точное число.

Что считается наблюдением

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

Эпизод	Применил?
Уточнил входные условия и ограничения до того, как начал решать	да
Бросился решать, не уточнив рамки задачи	нет
Сам прикинул порядок величин прежде, чем выбрать решение	да
Выбрал подход и обосновал его характером задачи	да
«Возьмём X» — без объяснения зачем	нет
Сам поднял слабое место своего решения и предложил, как его закрыть	да
Молча делает, не объясняя выборы	нет

• «Сколько пользователей и какой read/write ratio?» до проектирования → requirements_clarification, да
• «5М постов/день ≈ 60 QPS avg, ~600 peak» → estimation_skill, да
• «Возьмём очередь, потому что write-heavy и нужно сгладить пики» → tradeoff_reasoning, да
• Сам поднял «а что если упадёт основная БД?» → failure_thinking + proactiveness_driving, да

НЕ считается наблюдением: вопросы ученика про теорию («что такое X?»), знание в квизе (это spaced_review), пассивное согласие с твоим объяснением.

Наблюдение — это его собственное рассуждение/решение/артефакт, особенно вербализованное.

Особенность областей без оракула: think-aloud нужно ВЫЗЫВАТЬ

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

• «Прежде чем решать — что тебе нужно узнать про эту задачу?» (проверяет уточнение требований)
• «Почему здесь этот подход, а не альтернативный?» (проверяет рассуждение о компромиссах)
• «Что сломается первым, если нагрузка/объём вырастут?» (проверяет мышление о росте)
• «Что произойдёт, если этот шаг даст сбой?» (проверяет мышление об отказах)

Ответ ученика → наблюдение → обновление p_known. Вопрос — это и педагогика (Generation), и измерительный инструмент одновременно.

Триггер микроурока

Когда p_known < 0.4 И observations >= 2 → пробел подтверждён:

1. Добавь тему в spaced_review.json (для фактов — например ключевое правило выбора в этой области)
2. Предложи микроурок из соответствующего контентного скилла области
3. Включи концепцию в следующий challenge
4. В следующей задаче — наводящим вопросом обрати внимание на эту компетенцию

Пример (stealth): ученик три раза решил задачу, ни разу не подумав о сбойных сценариях. Соответствующая компетенция: p_known = 0.15, observations = 3. Триггер сработал.

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

Решение выглядит рабочим под нагрузкой. Давай проверим на прочность: представь, что в 3 часа ночи падает твоя главная БД. Что увидит пользователь? Что нужно, чтобы он этого не заметил?

Это наводящий вопрос, а не диагноз. Он начинает думать в нужную сторону, ты сопровождаешь открытие. Подумал в правильном направлении → observation+=1, p_known растёт.

Связь с типичными ошибками новичков

Каждая типичная ошибка области = сигнал конкретного пробела. Доменный слой даёт таблицу «ошибка → компетенция ↓». Общий принцип маппинга:

Тип ошибки	Какая компетенция проседает
Делает лишнее / усложняет (нарушение YAGNI)	рассуждение о компромиссах, уточнение требований
Прыжок в детали без уточнения рамок	уточнение требований
Пропустил обязательный шаг (расчёт/проверку)	соответствующий навык шага
Не подумал о сбойном сценарии	мышление об отказах
Выбор без обоснования	рассуждение о компромиссах

Когда НЕ действовать по диагностике

• Наблюдений мало (< 2) — одна попытка не паттерн.
• Ученик в фрустрации — никаких «у тебя пробел».
• Самые первые задачи — дай освоиться, не диагностируй с первого дня.
• p_known медленно, но растёт — это нормально, не ускоряй.

Stealth: что ученик видит / не видит

Видит: наводящие вопросы, микроуроки когда готов, предложения «а подумай ещё про X», свой прогресс в разборе задач. Не видит: слов «p_known/BKT/компетенция», файла competencies.json, своего «балла», сравнения с другими.

Исключение: если прямо спросит «как у меня дела?» — отвечай по-человечески, в процессной форме: называй, что заметно выросло, и над чем ещё работаете, без «балла» и без приговора.

Для overconfidence-профилей честный ответ особенно полезен (калибрует самооценку) — но в процессной форме.

Связь с другими скиллами

• session-flow — вызывает на main activity (выбор направления) и на update state (обновление файла)
• scaffolding — p_known < 0.3 → начинать с worked example / уровня опоры выше
• spaced-review — факты из дефицита идут в повторения
• feedback — правила реакции (никогда в лоб «у тебя пробел»)
• контентные скиллы области — источники микроуроков

Ссылки

• references/bkt-math.md — численные примеры обновления p_known
• references/observation-patterns.md — паттерны рассуждения → диагностика