Управляемый запуск проекта

ИИ-проверка работ с переносом утвержденных результатов в БРС

Проект предлагается запускать как третий интеграционный контур между `gtifem.ru` и `xfem.ru`: ИИ помогает проверить работу и подготовить решение, преподаватель утверждает академический результат, bridge переносит числовой балл в незаблокированную ведомость, финальная подпись остается у преподавателя.

human-in-the-loop Rule Pack BRS Adapter без автоподписи в MVP

HAR-файлов разобрано и сопоставлено

контура в целевой архитектуре

ключевых технических разрывов выявлено

фаз запуска MVP предложено

Что уже сделано

Это фиксирует проделанную работу в форме, которую можно показать руководителю как доказательство движения от идеи к проекту.

1. Разобрана механика `gtifem.ru`

Подтверждено, что модальное окно рецензирования уже встроено в HTML страницы портфолио. Открытие `Проверить` само по себе не является серверным действием.

`POST /portfolio/` с `action=print` возвращает печатную форму отчета.
Кнопка `Подписать` в печатном окне только раскрывает финальный submit в основном окне.
Реальное сохранение решения преподавателя идет через `POST /portfolio/` с `ACTION=edit`.

2. Разобрана механика `xfem.ru`

Подтверждено, что БРС работает через серверные HTML-формы, а не через чистый JSON API.

Ведомость создается через `POST /grade/report/custom/custom.php`.
Оценки сохраняются пакетным `POST /grade/report/custom/index.php`.
Подпись или блокировка ведомости выполняется через `POST /grade/report/custom/ajax/lock.php` с `action=locksaved`.

3. Выявлен безопасный момент интеграции

Bridge должен работать после сохраненного академического решения на `gtifem.ru` и до официальной блокировки колонки на `xfem.ru`.

Именно эта точка позволяет автоматизировать перенос результата, не снимая с преподавателя ответственность за академическое решение и финальную подпись.

4. Подготовлены проектные документы

As-Is и HAR Gap Analysis.
To-Be Integration Specification.
Инженерное ТЗ на MVP.
Рабочий план запуска MVP.
Демонстрационный HTML-пакет для руководства.

Evidence package / HAR

HAR-аналитика и пакет разобранных данных

Отдельный раздел для демонстрации руководству: какие браузерные сценарии были сняты, какие серверные действия найдены и почему текущая архитектура MVP опирается на реальные запросы, а не на предположение.

Пакет анализа 9 HAR-файлов

Разобраны и сопоставлены действия преподавателя в `gtifem.ru` и операции с ведомостями в `xfem.ru`.

Источник фактов HTML-form flow

Ключевые операции идут через формы, hidden-поля и POST-запросы, поэтому MVP должен иметь parser/resolver.

Главный вывод Запись до lock

Безопасная точка переноса балла находится до официальной блокировки ведомости и после утверждения преподавателем.

Что входит в HAR-пакет

В презентацию встроены управленческие выводы из технических материалов: As-Is карта процесса, HAR Gap Analysis, экранные заметки, To-Be спецификация и инженерное ТЗ MVP.

As-Is HAR Gap Analysis To-Be Engineering spec

Как читать этот раздел

Сначала смотрим доказанные endpoint-действия, затем риски интеграции, затем техническую базу. Это помогает быстро объяснить, почему нужен не просто ИИ-чат, а полноценный bridge между системами.

endpoint payload lock guard audit

Download center

Справочные материалы и проектные документы

Этот блок нужен для передачи проекта руководству: можно скачать весь пакет одним архивом или открыть отдельный документ по конкретному вопросу.

Скачать весь пакет ZIP

HAR

HAR Gap Analysis

Endpoint-выводы, разрывы интеграции, риски HTML-first систем и безопасная точка переноса результата.

Открыть HTML DOCX MD

As-Is

Карта текущего процесса

Как процесс работает сейчас: проверка, рецензия, ручной перенос балла и подпись ведомости.

DOCX TXT

Screens

Экранные заметки

Наблюдения по интерфейсам и действиям пользователя, которые помогают объяснить логику сценария.

TXT

To-Be

Целевая интеграционная модель

Будущая архитектура: Faculty Connector, Rule Pack, Approved Transfer Record, BRS Adapter и Audit Ledger.

DOCX TXT

ТЗ

Инженерная спецификация MVP

Техническая постановка: сущности, ограничения, адаптеры, guardrails, критерии приемки и этапы разработки.

DOCX TXT

Roadmap

Рабочий план запуска

Пошаговый маршрут перехода от презентации к предпроектному согласованию, пилоту и разработке.

DOCX TXT

HAR-наблюдение	Подтвержденный запрос	Что это доказывает	Решение для MVP
Открытие печатной формы проверки	`POST /portfolio/`, `action=print`	Это предпросмотр отчета, а не финальное сохранение решения.	Не считать preview событием переноса.
Сохранение рецензии и уровня	`POST /portfolio/`, `ACTION=edit`	Это durable approval преподавателя на стороне faculty-side.	Запускать transfer record только после этого события.
Создание ведомости в БРС	`POST /grade/report/custom/custom.php`	Новая колонка появляется через HTML-процесс, а не через удобный JSON API.	Автоматически создавать незаблокированную колонку и извлекать `column_id` из HTML.
Пакетное сохранение баллов	`POST /grade/report/custom/index.php`	БРС сохраняет не одну ячейку, а большую batch form.	Менять только целевые `grade_student_column` поля и сверять `oldgrade_*`.
Финальная подпись/блокировка	`POST /grade/report/custom/ajax/lock.php`, `action=locksaved`	После lock ведомость становится официально закрытой.	В MVP запретить автозапись в заблокированную ведомость и не включать автоподпись.

Пакет скачанных и проанализированных данных

`HAR Gap Analysis`: ключевые endpoint, payload-поля, риски HTML-first интеграции.
`As-Is Process Map`: текущий маршрут преподавателя от проверки работы до ручной записи балла.
`Screen Notes`: экранные наблюдения по действиям в `gtifem.ru` и `xfem.ru`.
`To-Be Integration Spec`: целевой bridge, transfer record, BRS Adapter и audit ledger.
`Engineering Spec`: техническое ТЗ на MVP, ограничения, фазы и критерии приемки.

Что HAR-анализ уже подтвердил

Подтверждена рабочая интеграционная точка: ИИ и bridge должны включаться после сохранения решения преподавателя и до блокировки БРС. Это сохраняет преподавателя в официальной зоне ответственности и позволяет автоматизировать перенос без опасной автоподписи.

Что еще нужно доснять перед разработкой

Свежий логин и получение актуального `sesskey` в `xfem.ru`.
Повторное открытие уже созданной ведомости и проверка lock-state.
Ошибочный сценарий: попытка записи в заблокированную ведомость.
Сценарий массового сохранения нескольких студентов в одной колонке.

Техническая база

Ключевые факты, которые нужно донести до руководства: проект опирается не на предположение, а на реальные точки сохранения, записи и блокировки.

Система	Подтвержденное действие	Endpoint / механизм	Значение для MVP
`gtifem.ru`	Сохранение решения преподавателя	`POST /portfolio/`, `ACTION=edit`	Это источник approved academic decision.
`gtifem.ru`	Предпросмотр отчета	`POST /portfolio/`, `action=print`	Это UI-ритуал перед подписью, но не durable save.
`xfem.ru`	Создание ведомости	`POST /grade/report/custom/custom.php`	Нужен BRS Statement Resolver, потому что созданный `column_id` надо извлекать из HTML после редиректа.
`xfem.ru`	Сохранение баллов	`POST /grade/report/custom/index.php`	Запись идет через batch form: нужно менять только целевые `grade_student_column` поля.
`xfem.ru`	Официальная блокировка	`POST /grade/report/custom/ajax/lock.php`, `action=locksaved`	В MVP автоматическая запись после lock запрещается, автоподпись не включается.

Справочная база

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

Семь ключевых разрывов, которые закрывает проект

Разные смысловые модели: уровень и рецензия на `gtifem.ru`, числовая ведомость на `xfem.ru`.
Разные идентификаторы студентов: нужен student crosswalk.
Нет универсального перевода уровня в балл: нужен Rule Pack.
Новая ведомость не возвращает удобный `column_id`: нужен HTML resolver.
Запись в БРС идет batch form, а не отдельным API на ячейку.
Официальность возникает на разных этапах: approval на `gtifem.ru`, lock/sign на `xfem.ru`.
Нет общего transfer id: нужен собственный audit ledger.

Решения, которые нужно утвердить до разработки

Пилотная дисциплина и типы работ.
Ответственный за Rule Pack и методическую шкалу.
Правила сопоставления студентов между системами.
Режим MVP: draft-only, assisted transfer или automatic fill into unlocked statement.
Границы ответственности преподавателя при переносе результата.
Регламент обработки ошибок, спорных кейсов и повторной проверки.

Риски и управляемые ограничения

Главный риск не в ИИ как таковом, а в интеграционной хрупкости двух HTML-first систем. Поэтому MVP должен начинаться с ограниченного контура и жестких guardrails.

Не писать в заблокированную ведомость.
Не включать автоподпись на первом этапе.
Не полагаться только на ФИО при поиске студента.
Не хардкодить `sesskey`, column id и временные значения из HAR.
Все операции переноса фиксировать в журнале.

Комплект подготовленных материалов

HAR Gap Analysis: ключевые выводы встроены в отдельный раздел HAR-аналитики
To-Be Integration Specification: целевая модель встроена в этот раздел
Инженерное ТЗ и рабочий план: основные шаги встроены в план запуска
HTML-демо будущего рабочего сайта

Глоссарий проекта

Единый словарь терминов, тезисов и англоязычных слов, которые встречаются в материалах MVP. Раздел рассчитан на быстрое объяснение руководству, методистам и разработчикам.

MVPMinimum Viable Product, минимально жизнеспособный продукт

управлениезапуск

Первая рабочая версия системы, которая доказывает ценность проекта на ограниченном контуре. Для этого проекта MVP не означает “все функции сразу”; он означает проверку полного маршрута от работы студента до контролируемого переноса балла.

As-Isописание текущего состояния “как есть”

аналитика

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

To-Beцелевая модель будущего процесса

архитектура

Описание того, как процесс должен работать после внедрения: ИИ формирует draft, преподаватель утверждает, bridge переносит балл, БРС остается официальной системой фиксации.

Rule Packверсионированный пакет правил оценивания

ИИметодика

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

Human-in-the-loopчеловек остается в критических точках решения

контроль

Принцип, по которому ИИ помогает, но не заменяет преподавателя в официальных решениях. В MVP преподаватель утверждает академический результат и сам выполняет финальную подпись БРС.

AI draftчерновик рекомендации ИИ

ИИteacher workflow

Предварительное предложение системы: уровень, комментарий, confidence и возможный балл. Это не финальное решение, а материал для преподавателя.

Confidenceоценка уверенности системы

ИИ

Показатель того, насколько система уверена в своей рекомендации. Низкий confidence должен не блокировать преподавателя, а подсвечивать необходимость внимательной ручной проверки.

Faculty-sideфакультетский контур `gtifem.ru`

gtifem.ru

Сторона процесса, где живут работы студентов, компетенции, рецензии, уровневые решения и событие преподавательского утверждения.

BRS-sideконтур БРС `xfem.ru`

xfem.ru

Официальная сторона фиксации числовых баллов: ведомости, колонки, сохранение оценок, агрегаты, подпись и блокировка.

Bridgeинтеграционный мост между `gtifem.ru` и `xfem.ru`

интеграция

Новый слой проекта, который превращает утвержденное академическое решение в контролируемую запись числового балла в БРС.

Faculty Connectorмодуль получения данных из faculty-side

connector

Компонент, который читает контекст работы, метаданные, файл, статус и сохраненное решение преподавателя на стороне `gtifem.ru`.

BRS Adapterмодуль безопасной записи в БРС

интеграция

Компонент, который находит студента, целевую ведомость и колонку, проверяет lock-state и записывает балл через текущий механизм `xfem.ru`.

Approved Transfer Recordзапись утвержденного переноса

data model

Главная сущность bridge-слоя: фиксирует work_id, student crosswalk, Rule Pack version, уровень, числовой балл, целевую ведомость, результат записи и audit trail.

Student Crosswalkтаблица сопоставления студентов

dataкритично

Связь между faculty-side student id и BRS-side student id. Нужна потому, что идентификаторы в `gtifem.ru` и `xfem.ru` не совпадают, а одного ФИО недостаточно для безопасной записи.

Audit Ledgerжурнал доказуемых действий системы

аудит

Журнал, где фиксируется каждое решение, версия правил, попытка переноса, успешная запись, ошибка или отказ из-за блокировки ведомости.

Idempotencyбезопасность повторного выполнения

надежность

Свойство операции, при котором повторная отправка того же результата не создает дублей, не завышает баллы и не ломает историю переноса.

Lock Guardзащита от записи в подписанную ведомость

защита

Проверка, которая запрещает автоматическую запись после официальной подписи или блокировки колонки в БРС.

Batch form postпакетная отправка HTML-формы

HTML-first

Механизм `xfem.ru`, где даже изменение одной оценки сохраняется большой формой со многими полями `grade_*` и `oldgrade_*`, а не отдельным API-запросом на одну ячейку.

HTML-first systemсистема, где главным контрактом является HTML-страница

legacy

Означает, что интеграция вынуждена работать с HTML-формами, hidden-полями, ссылками и DOM-структурами, потому что стабильного JSON API может не быть.

Endpointадрес и метод серверного действия

техника

Конкретная точка вызова, например `POST /portfolio/` или `POST /grade/report/custom/index.php`, через которую браузер сохраняет решение или балл.

column_idидентификатор колонки ведомости в БРС

xfem

Числовой идентификатор ведомости/колонки, который встречается как `sortitemid=493222`, `grade_student_493222` и `eid=i493222`.

courseidидентификатор курса в `xfem.ru`

xfem

Параметр БРС, который указывает конкретный курс или дисциплину. В HAR встречался пример `courseid=12636`.

categidкатегория ведомости в БРС

xfem

Параметр категории, например лекции, практика или другой раздел оценивания. Нужен при создании новой ведомости.

typeidтип ведомости внутри категории

xfem

Параметр, который выбирает конкретный тип ведомости, например `ЛЕКЦ`. Его нельзя угадывать: он должен браться из формы или справочника.

sesskeyсессионный ключ действия в `xfem.ru`

безопасность

Временный ключ, который используется в формах и ссылках БРС. Его нельзя хардкодить из HAR: адаптер должен получать актуальное значение из текущей авторизованной сессии.

`ACTION=edit`реальное сохранение решения на `gtifem.ru`

gtifemapproval

Ключевой HAR-факт: именно этот POST фиксирует преподавательское решение, уровень, тему и рецензию. Это правильный источник события для bridge.

`action=print`предпросмотр отчета на `gtifem.ru`

gtifem

Запрос возвращает печатную форму отчета. Это важный UI-шаг, но сам по себе он не является долговременным сохранением решения.

`action=locksaved`подпись или блокировка заполненной ведомости

official state

Официальный переход БРС в состояние подписанной или заблокированной ведомости. После этого автоматическая запись в MVP должна быть запрещена.

UI/UXинтерфейс и пользовательский сценарий

прототип

То, как преподаватель видит очередь работ, рекомендацию ИИ, расшифровку, кнопку утверждения, статус переноса и ошибки БРС.

Governanceуправление правилами и ответственностью

регламент

Набор управленческих правил: кто утверждает Rule Pack, кто отвечает за ошибки, кто допускает пилот, кто принимает решение о масштабировании.

KPI пилотапоказатели успешности запуска

пилот

Измеримые признаки успеха: сокращение времени проверки, доля ручных исправлений, число ошибок переноса, совпадение draft с решением преподавателя, стабильность адаптера.

Discoveryпредпроектное обследование

фаза 0

Этап, на котором команда подтверждает реальные процессы, данные, ограничения, роли, пилотную дисциплину и недостающие HAR-сценарии.

Work Registryреестр работ и статусов

backend

Внутренняя таблица или сервис, где система хранит работы, версии анализа, статусы проверки, решения преподавателя и готовность к переносу.

Parser / Resolverмодуль разбора HTML и поиска нужной сущности

интеграция

Parser извлекает данные из HTML, resolver сопоставляет их с нужной целью: студентом, ведомостью, колонкой или формой сохранения.

Целевая модель MVP

Будущая система должна быть не чат-ботом, а управляемым интеграционным контуром с понятной ответственностью.

Faculty Connector

Читает контекст работы, метаданные, решение преподавателя и событие `ACTION=edit`.

source eventportfolio

Rule Pack + AI

Формирует проект уровня, рецензию, объяснение и числовой балл по версионированным правилам.

rules-firstexplainable

BRS Adapter

Находит студента, ведомость, колонку, проверяет lock-state и пишет балл через текущую форму БРС.

idempotentlock guard

План запуска

Предлагаемый маршрут переводит проект из презентации в управляемую разработку без скачка сразу к полной автоматизации.

Фаза 0

Discovery и выбор пилотного контура

Переснять логин `xfem.ru`, подтвердить пилотную дисциплину, список работ, роли и ограничения. Результат: финальная карта данных и сценариев.

Фаза 1

Проектирование MVP

Утвердить Rule Pack schema, student crosswalk, transfer record, статусы, UI-сценарии и критерии приемки.

Фаза 2

Разработка ядра

Собрать Work Registry, AI draft, teacher approval, audit ledger и режим подготовки результата без записи в БРС.

Фаза 3

BRS Adapter

Реализовать запись в незаблокированную ведомость, проверку повторов, lock guard и верификацию после записи.

Фаза 4

Пилот и масштабирование

Запустить ограниченную группу, собрать KPI, исправить Rule Pack и подготовить решение о расширении.

Подробный промт для запуска работ

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

Execution prompt

Ты выступаешь как проектная команда для запуска MVP факультетской системы ИИ-проверки работ и переноса утвержденных результатов в БРС.

Контекст:
- есть две существующие системы: `gtifem.ru` и `xfem.ru`;
- `gtifem.ru` содержит работы студентов, рецензии, компетенции, уровневые решения и преподавательское утверждение;
- `xfem.ru` содержит ведомости, числовые баллы, batch-save форм, подпись и блокировку;
- по HAR подтверждено, что durable faculty-side approval возникает на `POST /portfolio/` с `ACTION=edit`;
- по HAR подтверждено, что BRS score save идет через `POST /grade/report/custom/index.php`;
- по HAR подтверждено, что official lock/sign идет через `POST /grade/report/custom/ajax/lock.php` с `action=locksaved`;
- в MVP нельзя автоматически подписывать ведомость и нельзя писать в уже заблокированную колонку.

Что уже сделано:
1. Разобрана механика `gtifem.ru`: модальное окно, preview report, финальное сохранение решения.
2. Разобрана механика `xfem.ru`: создание ведомости, edit mode, batch form save, lock endpoint.
3. Выделены разрывы: разные student id, нет универсальной формулы уровень -> балл, нет API created column id, запись идет через HTML-формы, нужна идемпотентность.
4. Подготовлена целевая логика: approved academic decision -> transfer record -> rule-based numeric conversion -> BRS write -> ручная подпись преподавателя.

Задача:
Подготовить рабочий план реализации MVP, затем перейти к разработке демонстрационного и пилотного контура.

Обязательные deliverables:
1. Data model:
   - Work
   - FacultyDecision
   - RulePack
   - AiAssessmentDraft
   - ApprovedTransferRecord
   - StudentCrosswalk
   - BrsStatement
   - BrsWriteAttempt
   - AuditEvent
2. UI/UX:
   - очередь работ;
   - карточка рекомендации ИИ;
   - окно teacher approval;
   - статус готовности к БРС;
   - журнал переноса;
   - экран ошибок и исключений.
3. Integration:
   - Faculty Connector;
   - BRS Statement Resolver;
   - BRS Form Writer;
   - Lock Guard;
   - idempotency strategy.
4. Rule Pack:
   - структура правил;
   - версия;
   - применимость;
   - шкала уровней;
   - перевод уровня в числовой балл;
   - ограничения и confidence.
5. Pilot plan:
   - одна дисциплина;
   - один-два типа работ;
   - ограниченный преподавательский контур;
   - KPI: время проверки, доля ручных исправлений, ошибки переноса, совпадение решения преподавателя с draft.

Реализационные ограничения:
- сохранять преподавателя в точках официальной ответственности;
- не делать автономную подпись БРС в MVP;
- не полагаться только на ФИО при сопоставлении студентов;
- не писать в заблокированные ведомости;
- все записи делать идемпотентно;
- все решения логировать с версией Rule Pack.

Первый практический шаг:
Собрать clickable prototype и технический skeleton:
- статический UI для руководства и пилота;
- mock transfer flow;
- schema transfer record;
- parser/resolver для HTML-структуры BRS на тестовых данных;
- журнал аудита;
- checklist для пересъемки недостающего HAR по логину `xfem.ru`.