generate-zvit-and-shodennik

name: generate-zvit-and-shodennik description: Generate a pre-diploma practice report (звіт з практики, .pdf) and practice diary (щоденник практики, .pdf) for the Odesa Polytechnic standard — content derived from the existing thesis/ artifacts, conformant to docs/diploma-rules/references/ZVIT-RULES.md and SHODENNYK-RULES.md (text formatting per docs/diploma-rules/RULES.md), and styled after the reference Звіт.docx / Щоденник.docx. Use when the user asks to generate, build, draft, or scaffold the practice report / diary (звіт / щоденник практики).

Generate Звіт + Щоденник — генерація звіту і щоденника практики за правилами «Одеської політехніки»

Збирає два PDF: thesis/practice/zvit.pdf (звіт з переддипломної практики) і thesis/practice/shodennyk.pdf (щоденник практики), які за побудовою відповідають правилам і повторюють структуру еталонних Звіт.docx / Щоденник.docx. Звіт — це стиснена версія роботи, тож зміст береться з уже згенерованої роботи в thesis/, а не вводиться новий. Щоденник — фіксована офіційна форма. Мета — не «накидати документи», а видати звіт і щоденник, що проходять /grill-zvit-and-shodennik без BLOCKER/MAJOR.

Вхід

Аргументи (усі необов'язкові):

• тека роботи — типово thesis/;
• тека виводу — типово thesis/practice/.

Метадані (ПІБ, група, спеціальність, ОПП, керівник від університету) тягнуться з thesis/00-tytulnyi-arkush.md. Практико-специфічні дані, яких немає в роботі — назва підприємства, період практики (початок/кінець), керівник від підприємства, індивідуальне завдання, роботи Календарного графіку — зібрати інтерактивно через пряме питання до користувача, не вгадувати. Якщо теки роботи немає (нема звідки брати зміст звіту) — попросити спершу згенерувати роботу через /generate-diplom.

Джерела істини (читати перед генерацією)

1. docs/diploma-rules/references/ZVIT-RULES.md — структура й змістові вимоги звіту.
2. docs/diploma-rules/references/SHODENNYK-RULES.md — повна офіційна форма щоденника та правила крос-консистентності. Не рекомендації.
3. docs/diploma-rules/RULES.md — текстові константи оформлення (поля, шрифт, інтервали, заголовки, рисунки, таблиці, сценарії, список джерел).
4. docs/diploma-rules/references/Звіт.docx / Щоденник.docx — візуальний еталон структури й вигляду.
5. Тека роботи thesis/ — джерело змісту згідно з картою нижче.

За розбіжності ZVIT-RULES.md / SHODENNYK-RULES.md (структура) і RULES.md (текстове оформлення) мають перевагу; для вигляду форми щоденника — Щоденник.docx.

Карта «робота → звіт/щоденник»

Рисунки. Імена рисунків у роботі — <розділ>-<n>.png. У звіті проєктування — розділ 2, тож рисунки розділу 4 роботи стають рисунками розділу 2 звіту: знайти фактичні файли в thesis/figures/ і скопіювати/перейменувати у thesis/practice/figures/ під нумерацію звіту (use-case → 1-4.png; архітектура/ER з розд. 4 → 2-1.png/2-2.png; скриншоти аналогів → 1-1..1-3.png). Резолвити за реальними іменами, не хардкодити.

Процедура

1. Підготовка

• Прочитати ZVIT-RULES.md, SHODENNYK-RULES.md і RULES.md повністю.
• Прочитати джерела з thesis/ за картою; витягнути актуальність/мету/завдання/об'єкт/ предмет (з 03-vstup.md), специфікацію вимог і сценарії (з 04-rozdil-1.md), проєктування (з 07-rozdil-4.md), висновки (з 11-zagalni-vysnovky.md); зібрати таблицю аналогів зі стовпцем «Власна розробка».
• Зчитати метадані з 00-tytulnyi-arkush.md.
• Через прямі питання до користувача зібрати прогалини: назва підприємства, період практики (ISO-дати), керівник від підприємства, індивідуальне завдання, роботи Календарного графіку. Звірити, що роботи графіку й періоди узгоджені з розділами звіту.

2. Інструмент

• Переконатися, що в thesis/.venv встановлено weasyprint (вже є для build_pdf.py) і PyYAML (для shodennyk-data.md); якщо ні — встановити в цей venv.

3. Підготувати рисунки

• Скопіювати/симлінкнути потрібні PNG з thesis/figures/ у thesis/practice/figures/ під нумерацію звіту (див. карту). Якщо діаграми немає — згенерувати наявним thesis/render_diagrams.sh.

4. Генерація вихідних файлів

• Написати 8 файлів zvit-00-tytul.md … zvit-07-dzherela.md за інваріантами RULES.md: структурні заголовки ВЕЛИКИМИ по центру; підрозділи 1.1/2.1 без крапки; на кожен рисунок/таблицю/сценарій — посилання в тексті до появи; підпис рисунка під ним, заголовок таблиці над; сценарії у форматі ZVIT-RULES.md §6; переліки з :/;/.; джерела за ДСТУ 8302:2015. Дотримати порядок 8 елементів (ZVIT-RULES.md §1).
• Заповнити shodennyk-data.md (YAML-блок) усіма полями: метадані, індивідуальне завдання, Календарний графік (роботи ↔ розділи звіту), Робочі записи (ISO-діапазони покривають період без розривів і відповідають графіку). Поля підписів/печаток/оцінок — лишити порожніми бланками.

5. Збірка PDF (через відтворюваний скрипт)

• Запустити thesis/.venv/bin/python thesis/practice/build_practice.py (будує обидва PDF; або … build_practice.py zvit / … shodennyk окремо). Отримати zvit.pdf і shodennyk.pdf. Скрипт повторно використовує thesis/build_pdf.py (ті самі константи).

6. Очищення від AI-ознак

• Прозу звіту (вступ, тіло розділів, характеристику підприємства, висновки) і текстові робочі записи щоденника прогнати через скіл humanizer. НЕ гуманізувати структурні константи: нумерацію, підписи рисунків/таблиць, бібліоописи, поля форми щоденника.

7. Самоперевірка (обов'язково)

• Прогнати /grill-zvit-and-shodennik thesis/practice/ thesis/. Якщо є BLOCKER або MAJOR — виправити джерела, перебудувати й перегенерувати, доки обидва вердикти не стануть PASS / PASS WITH FIXES без BLOCKER/MAJOR. Лише тоді повідомляти готовність.

Принципи

• Правила — не побажання. Документи не «готові», доки /grill-zvit-and-shodennik не підтвердив відсутність BLOCKER/MAJOR.
• Звіт візуалізує роботу. Вступ/вимоги/проєктування/висновки — з thesis/; нових фактів про продукт не вводити.
• Щоденник — фіксована форма. Відтворити всі блоки; поля підписів/печаток/оцінок — порожні бланки. Не вигадувати підписів, відгуків, оцінок.
• Крос-консистентність обов'язкова. ПІБ/група/спеціальність/підприємство/період мусять збігатися між zvit-00-tytul, shodennyk-data.md і thesis/00-tytulnyi-arkush.md.
• Не вигадувати фактів про підприємство: відсутнє позначати [ПОТРЕБУЄ ДАНИХ: …].
• Уточнювати неоднозначне (підприємство, період, роботи графіку) до генерації, а не після.

Local Codex adaptation for this project

The upstream skill was written for a repository that stores generated work under thesis/. In this project, use these local paths instead:

• Diploma artifact folder: docs/generated-diploma/.
• Latest generated DOCX/PDF files: docs/generated-diploma/dyplomna-robota-team-task-manager-fixed_v4.docx and docs/generated-diploma/dyplomna-robota-team-task-manager-fixed_v4.pdf, unless the user points to another file.
• Extracted/restored figures and screenshots: docs/generated-diploma/assets/; fallback working copies may also exist in work/restored-figures/.
• Diploma builder: tools/build_diploma_docx.py.
• Diploma rules and references stay at docs/diploma-rules/.

When this skill says thesis/, resolve it to docs/generated-diploma/ for this repository. When it asks for markdown chapter sources that are not present locally, derive content from the current generated DOCX/PDF and ask the user before inventing missing facts. Put new presentation or practice outputs under docs/generated-diploma/, for example docs/generated-diploma/presentation.pptx and docs/generated-diploma/practice/.