Шаблони/Випробування

Програма та методика попередніх випробувань

Програма та методика проведення попередніх випробувань. Тіло — табличне; рядки беруться з матриці вимог (status=covered).

skeleton.gdoc

Як це працює

01
skeleton.gdoc

Вова править розмітку SOD у Google Docs. Placeholder-и виглядають як smart chips, не як {{шаблонізатор}}.

02
UI-конфіг + KB

Цей екран. Вова визначає, звідки тягнути кожен placeholder. KB-елементи прив'язує через мульти-селект, не через файл.

03
batchUpdate → Drive

Коли Romina/Yana запускає генерацію — конвеєр робить копію skeleton, тягне дані з матриці і KB, шле batchUpdate у Google Docs API. Результат — нова версія у Drive.

Версія
v2.4
Оновлено
22 квіт 2026
Редактор
Vova Ganziy
Placeholders
14
LLM-секцій
1 / 11
Шаблонізовано
85%

Placeholders

Вова бачить форму, не YAML. Кожен placeholder має джерело: project_meta (з трекера), matrix (з матриці вимог), kb (з бази знань), llm (генерується), fixed (системний).

project_meta8matrix1kb3llm1fixed1
project_metaЗ трекера проєкту · 8
{{project_name}}
Назва проєкту
приклад: Vector
{{contract_number}}
Номер договору
приклад: ДКТ-2026-VEC-01
{{client_name}}
Замовник
приклад: МОН України
{{stage}}
Етап
приклад: Етап 1. Розгортання та міграція даних
{{exam_date}}
Дата випробувань
приклад: 2026-05-15
{{exam_location}}
Місце проведення
приклад: м. Київ, стенд Замовника
{{representatives}}
Список учасників випробувань
приклад: Виконавець: Vova Ganziy. Замовник: за окремим списком
{{appendix_b}}
Додаток Б: реквізити сторін
matrixЗ матриці вимог · 1
{{table_5_2}}
Таблиця 5.2 — перевірки відповідності
Рядки з матриці зі status=covered + tests.program_pop. Автоматично.
kbЗ бази знань · 3
{{table_5_1}}
Таблиця 5.1 — перевірка комплектності документів
Канонічна таблиця 5.1 з KB — 8 рядків, однакова на всі проєкти.
{{glossary}}
Глосарій (8 термінів)
Канонічний глосарій з KB
{{conclusions_template}}
Стандартні формулювання висновків
llmЗгенеровано LLM · 1
{{introduction_bridge}}
Вступ (адаптований під специфіку проєкту)
Один параграф, що пов'язує специфіку проєкту з постановою №205. Згенеровано LLM з опису проєкту, на основі прикладів з KB.
fixedСистемний · 1
{{footer_audit}}
Audit footer — версія шаблону, KB, snapshot

Структура документа

11 секцій. Кожна — окремий вузол у конвеєрі: статичний текст з KB, підстановка placeholder-ів, динамічна таблиця з матриці, або LLM-блок (з людським ревью).

01

1. Титульна сторінка

placeholder

Назва проєкту, договір, замовник, етап, дата.

{{project_name}}{{contract_number}}{{client_name}}{{stage}}{{exam_date}}
02

2. Перелік умовних позначень і скорочень

static

Глосарій з 8 канонічних термінів.

{{glossary}}
03

3. Загальні відомості

llm

Вступний параграф адаптується під специфіку проєкту. LLM генерує з опису.

{{introduction_bridge}}
04

4. Об'єкт випробувань

placeholder

Опис об'єкта — береться з ТЗ §1.

{{project_name}}{{stage}}
05

5.1. Перевірка комплектності документів

dynamic_table

Канонічна таблиця 5.1 з KB. 8 рядків — однакова на всі проєкти.

{{table_5_1}}
06

5.2. Перевірка відповідності функціональності

dynamic_table

Тут серце. Кожен рядок — вимога з матриці (status=covered, tests.program_pop присутній). Поля: №, що перевіряємо, методика, очікуваний результат, ID вимоги.

{{table_5_2}}
07

6. Висновки

static

Стандартні формулювання з KB.

{{conclusions_template}}
08

7. Учасники випробувань

placeholder

Список з project meta.

{{representatives}}
09

8. Підписи

placeholder

Прізвища підписантів з обох сторін.

{{representatives}}
10

Додаток Б. Реквізити сторін

placeholder

Контактні дані Виконавця і Замовника.

{{appendix_b}}
11

Footer (генерується автоматично)

static

Згенеровано zvitnist v0.4 / template v2.4 / KB 2026-04-25 / matrix snapshot {{matrix_hash}}

{{footer_audit}}

Прив'язки бази знань

Версіонується окремо. Коли оновлюється KB-елемент — генерації автоматично підхоплюють нову версію (стара версія залишається в audit trail).

Уся База знань
postanovav2026-03-25
Постанова Кабміну №205

Про затвердження Положення про порядок створення інформаційних, інформаційно-телекомунікаційних систем у державних органах. Додаток 2 — ТВ, додаток 3 — ТЗ, додаток 4 — ДСТУ.

оновлено 25 бер 2026відкрити
glossaryv1.4· 8 елементів
Канонічний глосарій (8 термінів)

Стандартний глосарій термінів для звітних документів. Однаковий на всі проєкти SOD.

оновлено 15 квіт 2026
phrase_libraryv1.2· 8 елементів
Таблиця 5.1 — перевірка комплектності документів

Канонічна таблиця 5.1 для програм випробувань — 8 рядків, однакова на всі проєкти.

оновлено 15 квіт 2026
phrase_libraryv1.6· 24 елементів
Стандартні формулювання висновків протоколу

Бібліотека стандартних фраз для розділу «Висновки» протоколів. ~25 формулювань для типових сценаріїв.

оновлено 30 бер 2026

Footer-коментар

Автоматично додається в кінець кожного згенерованого документа. Це audit trail — замовник бачить, з якого snapshot матриці і версії KB народився документ.

Прев'ю генерованого footer-блоку
---
Згенеровано zvitnist v0.4-demo · 12 трав 2026
Шаблон: program-vyprob v2.4 · skeleton.gdoc (rev. 2026-04-22)
KB snapshot: 2026-04-25 (postanova-205 v2026-03-25, glossary-canonical v1.4, table-5-1 v1.2, conclusions v1.6)
Matrix snapshot: vector / etap-1 / sha 8f3a91c · 23 рядки status=covered
Генерувала: Vova Ganziy через Claude Desktop · MCP tool: generate_document
Audit ID: zv-gen-2026-05-12-0942-vec-progr-pop
Не редагується вручну. Прибирається з PDF-експорту для замовника (опціонально), але залишається у внутрішньому Google Doc для трекінгу.