Постанова КМ №205 · 15+ SOD-проєктів · внутрішній конвеєр

Звітні документи держпроєктів — без переписування з нуля.

Жива матриця вимог замість регенерації покриття з тексту ТЗ. Програми, протоколи й звіти flow з матриці. Документи живуть у Google Drive, трекери — у Confluence, інтерфейс генерації — у Claude Desktop.

Без копій документів
Find-and-replace in place
Audit trail на кожну зміну
zvitnist · Vector · Requirements Matrix
73%
ID / ТВ
Вимога
Покриття
Статус
VEC-3.2.1
ТВ §3.2.1
Реєстрація педагога через ДЕМ-ID
інстр. §2.1 · метод. №4
Покрито
VEC-4.1.1
ТВ §4.1.1
Захист персональних даних
інстр. §5.3 · опис §4.2
Покрито
VEC-4.2.1
ТВ §4.2.1
Доступність WCAG 2.1 AA
аудит §2.1 · програма №15
Очікує
VEC-3.3.3
ТВ §3.3.3
Зворотний зв'язок після курсу
Очікує
VEC-5.1.1
ТВ §5.1.1
Інтеграція з реєстром педагогів
інстр. §6.1 · опис §5.1
Покрито
+ 23 рядки · авто-засіяно з ТЗ · 20 апрувнуто
Що болить

Кожен проєкт — 14-17 документів, які перетікають один в одного. Скопіюй неправильно — отримай аудит.

01

Cross-doc coverage

Чи всі вимоги ТВ покриті в ТЗ? Чи все з ТЗ є в програмі випробувань? Зараз — руками, у Confluence-таблиці. Romina (тех-писець) вела таку для ЄДКІ-2024 — 17 рядків вручну.

«Цю штуку я не поборов»
— Вова, recording з пілоту
02

Cross-doc consistency

Реквізити, номер договору, етап, абревіатури — повторюються у 13 документах проєкту. Один раз помилився — каскад правок.

«Базова структура — за 8 годин»
— Вова, але далі вручну
03

DOCX-форматування

TNR 14pt, інтервал 1.5, нумерація 1.→1.1.1.1., таблиці, рисунки, TOC. SOD-чек-ліст затверджено Світланою. Python-docx губить коменти і smart chips.

«Вліз у форматування»
— Вова, чому власний скрипт не злетів
Архітектура — у трьох шарах

Один бекенд, два інтерфейси. Користувач — Claude Desktop, адмін — веб.

Інтерфейс — Claude Desktop

Для щоденної роботи Вови, Romina, Yana
  • Чат з MCP-tools — як Slack
  • Без git, без CLI, без YAML
  • «Згенеруй методику для Vector етап 1»
  • Веб-адмінка — лише для CRUD матриці і конфігурації шаблонів
Показати сценарій

Серце — Requirements Matrix

Жива таблиця, з якої flow всі документи
  • Один рядок — одна вимога ТВ → ТЗ → docs → tests
  • Status, confidence, approved_by, notes
  • Materialization того, що Romina вже робила руками
  • Програми/протоколи — рендериться з матриці
Подивитися матрицю Vector

Дані — Drive + Confluence

Pluggable adapters, не lock-in
  • Документи: Google Drive (find-and-replace in place)
  • Метадані: Confluence-трекер
  • Шаблони: skeleton.gdoc + UI-конфіг + KB
  • Pluggable: SaaS-клієнти можуть бути на Notion / SharePoint
Схема архітектури
Що бачимо у цьому прототипі

UX-візію, не код. Усі дані — мок.

Це непрацюючий прототип. Жодного справжнього Google Drive API, MCP, чи LLM під капотом — лише статичні мок-дані. Мета прототипу — швидко показати директору і Вові, як виглядатиме реальний продукт з точки зору користувача: що зрозуміло, що зайве, чого бракує.

Дані для моку — справжні: список 15 документів Vector, 17-рядкова coverage-таблиця Romina (ЄДКІ-2024), реальні посилання на Confluence-трекери, реальні дедлайни (15.05, 18.05).

Що це НЕ робить
Перш ніж клікати — узгодимо очікування.
  • Не зберігає зміни — все скине після refresh
  • Не викликає Google Docs API і не пише в Drive
  • Не запускає реальний LLM — все згенероване заздалегідь
  • Cinema-чат — це scripted demo, не live MCP
  • Кнопки «Згенерувати» / «Approve» імітують виклик