hleb/md_to_gost
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

v0.5.5
Example document / build (push) Has been cancelled
Details
Python application / build (push) Has been cancelled
Details

Browse Source 
Update Promt
Updata to-do
This commit is contained in:
Hlebushek
2026-09-19 13:59:55 +03:00
parent 5fb5010571
commit 7fc112e2ce
50 changed files with 3305 additions and 3829 deletions
Download Patch File Download Diff File Expand all files Collapse all files
AI-Docs_WriteHuman/docs/README.md
+22
View File
@@ -0,0 +1,22 @@
# Документация md2gost
Конвертер Markdown → DOCX для учебных работ (ТЗ МИРЭА / ГОСТ 7.32, ПИС, АПИД).
## Содержание
1. [Быстрый старт](quickstart.md) — установка, первое окно, exe
2. [Синтаксис Markdown](markdown.md) — чем диалект отличается от обычного MD
3. [Схемы и диаграммы](schemes.md) — UML, Mermaid, IDEF0, DFD (вшитый Graphviz / Kroki), настраиваемые схемы
4. [ArchiMate 3.2](archimate.md) — генерация схем (макросы PlantUML, связи, viewpoints)
5. [Типы документов](types.md) — coursework, practice, vkr, PIS_custom, APID_coursework
6. [CLI и GUI](cli-gui.md) — флаги и соответствие в интерфейсе
7. [Автотитульник](title.md) — `info_conv.yaml`, блок `title`, ФИО/группа
8. [Кастомные стили (JSON)](styles.md) — оверлей полей и стилей абзацев
9. [Промпты для ИИ](prompts.md) — генерация `.md`, расширение промпта схемами
10. [Импорт Word → Markdown](word2md.md) — DOCX в диалект md2gost (word2md)
Исходный код конвертера: [`md2gost/`](../md2gost/). Примеры: [`examples/`](../examples/).
Полная карта репозитория (архитектура, все функции CLI/GUI и модули кода): [`PROJECT.md`](../PROJECT.md).
В GUI: **Справка → Документация** — тот же набор страниц (вшит в exe).
AI-Docs_WriteHuman/docs/TODO.md
+186
View File
@@ -0,0 +1,186 @@
# Незакрытые задачи после аудита
Состояние на 10 сентября 2026. Всё перечисленное — то, что осталось после прохода по плану оптимизации. Что уже сделано, см. [audit-report.md](audit-report.md).
Тесты сейчас: **320 passed, 1 skipped, 174 subtests**, полный прогон 11.85 с. Ничего не закоммичено — всё лежит в staging и рабочем дереве.
---
## P0 — сломает сборку, если не сделать
### `mdexport/` не добавлен в git
Пакет `mdexport/` (общий обходчик AST для `md2latex` и `md2fodt`) создан, но остался **untracked**, при этом на него уже завязаны:
- `pyproject.toml` — перечислен в `[tool.hatch.build.targets.wheel].packages`
- `md2latex/emitter.py`, `md2latex/escape.py`
- `md2fodt/emitter.py`, `md2fodt/escape.py`
На свежем клоне оба конвертера упадут с `ModuleNotFoundError`, сборка колеса тоже. Локально работает только потому, что файлы лежат на диске.
```powershell
git add mdexport/blocks.py mdexport/inline.py mdexport/labels.py mdexport/__init__.py
git status --short mdexport
```
Скомпилированные `.pyc` внутри уже покрыты правилом `__pycache__/`, добавлять их не нужно.
---
## P1 — найденный баг, теряет данные
### `word2md` выбрасывает пункты списка при смене его типа
Найден при разборе `_handle_paragraph`. Баг **существовал и до рефакторинга**, его сохранили намеренно, чтобы правка осталась поведенчески нейтральной.
`word2md/walker.py`, строки 406-429. Оба обработчика списков заканчиваются на `return []`, выбрасывая накопленный `out` — притом что `_flush_code(out)` и `_flush_list(out)` внутри уже успели в него дописать:
```python
def _as_numbered_list_item(self, para: _Para, out: list[Block]) -> list[Block] | None:
if not paragraph_has_numpr(para.paragraph):
return None
self._flush_code(out) # может дописать в out
...
self._append_list_item(ordered, body, out) # внутри вызывает _flush_list(out)
return [] # <- out выброшен
```
`_append_list_item` (строки 431-437) при смене типа списка вызывает `_flush_list(out)`, который сбрасывает накопленные пункты в `out`. После чего `return []` их теряет. Соседний `_as_plain_paragraph` (строка 439) в такой же ситуации корректно делает `return out`.
Воспроизведение: два упорядоченных пункта с `numPr`, за ними пункт-буллет. Оба упорядоченных пропадают из результата. Тот же механизм теряет и забуференный код, если он был.
Порядок работ: сначала красный тест на исчезающие пункты, потом замена `return []` на `return out` в обоих обработчиках, потом проверка, что побайтовая сверка вывода на остальных документах не поехала (она поедет только там, где баг срабатывал).
---
## P1 — решено, но не выполнено
### Калибровка Courier New 10 пт
Ты выбрал вариант «10 пт канон по табл. 4.1, добавить калибровку и перевести тест-фикстуру». **Не сделано** — я не успел запустить задачу до конца сессии.
Что именно нужно, в `md2gost/renderable/paragraph_sizer.py`, метод `Font.get_line_height` (строки 78-83):
```python
# TODO: make it work for all fonts
if "Times" in str(self._face.family_name) and self._freetypefont.size == 14:
return Pt(16.05)
if "Courier" in str(self._face.family_name) and self._freetypefont.size == 12:
return Pt(13.61)
```
Сейчас калиброванная ветка есть только для Courier 12 пт. Замеры, снятые в ходе аудита:
| Размер | Возвращает сейчас | Фактическая высота |
|---|---|---|
| Courier 10 пт | 11.000 | ≈ 11.34 |
| Courier 11 пт | 12.000 | — |
| Courier 12 пт | 13.610 (калибровка) | 13.61 |
| Courier 14 пт | 16.000 | — |
Целые числа выдаёт округление FreeType; калибровочные ветки существуют ровно затем, чтобы подменить округление реальным значением Word. Пропорция от 13.61 при переходе 12 → 10 пт даёт примерно 11.34.
Итог: пока ветки для 10 пт нет, **каждая строка листинга меряется примерно на 3% короче**, и на длинных листингах разъезжаются разрывы страниц.
Порядок работ:
1. Добавить ветку `Courier` + размер 10 → `Pt(11.34)`. Лучше сначала подтвердить число замером в Word через COM, а не принимать пропорцию на веру.
2. Перевести `tests/__init__.py` (строка 27) с `Pt(12)` на `Pt(10)`, чтобы фикстура совпадала с `style_config.py:305` и табл. 4.1.
3. Прогнать `tests/test_paragraph_sizer.py` — серия `test_count_lines_courier1..10` завязана на текущую высоту, ожидаемые значения поедут.
Не делай пункт 2 без пункта 1 — иначе калиброванная ветка перестанет срабатывать, и замер станет хуже, чем сейчас.
### `Other_Code/` — 59 файлов, 1158 КБ
Это была Фаза 4.2 плана, и я её просто не назначил ни одному исполнителю при раскладке работ. Каталог до сих пор полностью в git.
Ни одного импорта из `md2gost`, `word2md`, `md2latex`, `md2fodt`, `tests/`; не упоминается в `.spec`, `.bat`, `.github/workflows/`, `pyproject.toml`. Единственные ссылки — раздел 12 в `PROJECT.md` и внутренние перекрёстные ссылки самого каталога.
Команды и три варианта действий расписаны в [git-cleanup.md](git-cleanup.md), раздел 1.
### Личные документы в корне
`ТарасовИА_КР_v3.docx` (2326 КБ) и `Практическая_работа_6.docx` (42 КБ) — ФИО прямо в имени файла. Ты сказал, что уберёшь руками; команды и предупреждение про ловушку с `md2gost/Template.docx` в [git-cleanup.md](git-cleanup.md), раздел 2.
---
## P2 — открытые вопросы по методичке
### «С новой страницы» для надписи листинга
Табл. 4.1 (`docs/reference/method-mirea-2022.txt`, строки 714-715) в блоке «Положение на странице» перечисляет и «Не отрывать от следующего», и «С новой страницы».
В `md2gost/style_config.py` у стиля `Caption Listing` (строки 278-291) есть `keep_with_next=True`, но нет `page_break_before=True`. Вопрос не праздный: в репозитории есть целая система режимов `--listing-continuation`, так что отсутствие разрыва может быть осознанным выбором. Плюс `Caption.__init__` теперь явно ставит `page_break_before = False`, чтобы не плодить пустые страницы при сочетании с `keep_with_next` — то есть менять придётся согласованно в двух местах.
Решение нужно принять до того, как кто-то «починит» это по табл. 4.1 в лоб.
### Правило `heading.empty` ложно срабатывает внутри листингов
Новое правило в `md2gost/checker/__init__.py` не вырезает fenced-блоки, поэтому одинокая строка `#` внутри блока кода будет засчитана как пустой заголовок. Поведение консистентно с уже существующим `HEADING_RE` в том же файле, то есть это общая для checker'а проблема, а не привнесённая. Чинить имеет смысл сразу для всех проверок заголовков.
---
## P3 — не начатое из Фазы 6
Всё это помечено в плане как опциональное. Ничего из перечисленного не сделано, кроме общего обходчика AST и разбора `word2md/_handle_paragraph`.
### Разбиение `idef0.py`
1935 строк (сейчас 74 КБ). God-функции: `_parse_arrow_line` (~177 строк), `_draw_kit_form` (~121), `_route_icom` (~110), `_draw_arrow` (~83), `_layout_arrow_label` (~80).
Предлагаемая раскладка в пакет `idef0/`: `model.py`, `parse.py`, `layout.py`, `routing.py`, `scene.py`, `draw.py`, `render.py`, с реэкспортом публичного API из `__init__.py` ради тестов. Выигрыша в скорости не даёт, только читаемость.
Отдельно там же: `_Scene.to_png()` и `_Scene.to_svg()` дважды обходят один и тот же список операций. Можно сгенерировать SVG и растеризовать его в PNG.
### Разбиение `gui.py`
1695 строк (82 КБ) в одном классе `Md2GostApp`: главное окно, шесть диалогов, редактор UML-схем на ~270 строк, композер промптов, логика перезаписи файлов, потоки конвертации, загрузка ассетов.
Раскладка: `gui/windows/`, `gui/widgets.py`, `gui/convert_runner.py`, а `Md2GostApp` оставить тонкой оболочкой.
### Ленивые импорты
`md2gost/pipeline.py` (строки 15-19) и `md2gost/gui.py` (строки 11-32) тянут весь конвейер на старте: `docx`, pygments, PIL, lxml. `python -m md2gost --help` платит за это полную цену. Matplotlib и playwright уже ленивые — сделать так же с остальным.
### Общий сборщик `ConvertRequest`
`gui.py` (строки 1730-1760) и `__main__.py` (строки 272-317) дублируют маппинг примерно двадцати полей и уже разошлись: дефолт типа документа в GUI `coursework`, в CLI `practice`.
### Флаг `--open`
`__main__.py` строки 315-316: `open_when_done=bool(args.debug)`. Открытие готового файла привязано к дебагу, отдельного флага нет, хотя в GUI есть галочка.
### Скачивание PlantUML блокирует Tk
`gui.py` строка 1537 — синхронный вызов `fetch_plantuml_jar`, тогда как Graphviz (1576) и Chromium (1622) рядом уже качаются в отдельном потоке.
---
## P3 — документация не догоняет код
### Таблицы модулей в `PROJECT.md` не знают про `mdexport`
Новый пакет `mdexport` не попал в разделы с картой репозитория и перечнем модулей — исполнитель не владел этим файлом и намеренно его не трогал. Заодно стоит убрать оттуда упоминания удалённых прототипов, если раздел 12 их ещё перечисляет.
---
## P4 — замечания исполнителей, оставленные как есть
- **`uv.lock` в порядке.** `uv lock` отработал с сетью, добавил matplotlib 3.11.1 с транзитивными зависимостями, `uv lock --check` проходит. Лок синхронен и по matplotlib, и по `pywin32` — пересобирать не нужно.
- **Playwright закрывается в конце `convert()`.** Это и было целью Фазы 3.4, но у GUI-сценария появилась плата: при каждой следующей конвертации браузер поднимается заново вместо переиспользования. Если mermaid-диаграммы конвертируются часто, стоит подумать про пул с таймаутом.
- **Кастомный `--plantuml-jar` другой версии не отражается в ключе кэша.** Префикс использует прибитую константу `PLANTUML_VERSION`. Фингерпринт самого файла закрыл бы дыру, но заставлял бы кэш протухать при каждом появлении и исчезновении jar.
- **Версия jar в ключе кэша задевает и Kroki-рендеры**, потому что не-mermaid типы делят один путь кэша между бэкендами. Бамп версии обесценит и записи, отрисованные через Kroki. Это лишняя перерисовка, не более.
- **Если одна диаграмма роняет батч-JVM, отбрасывается вся пачка** и каждая диаграмма уходит на свою JVM. Корректно, но стоит одной впустую потраченной JVM.
- **`--syntax-highlighting --strict --check` теперь завершается с кодом 1**, потому что новое правило `listing.syntax_highlighting` под `--strict` становится ошибкой. Это ровно то поведение, которое закладывалось, но про него надо помнить в скриптах.
- **Playwright изредка печатает `Task was destroyed but it is pending`** на выходе интерпретера при большом комбинированном прогоне. Не воспроизвелось повторно, все тесты проходят, тот же путь закрытия вызывался и до правок.
- **Правила игнора `/tmp_*.png` и `/tmp_*.puml`** захватили рабочие черновики `tmp_org_full.*`, `tmp_org_uml.*`, `tmp_arch.*`. Файлы на диске целы, но из `git status` пропали.
- **`todo.txt` в корне** остался нетронутым — это твой личный блокнот, я его не трогал и не сливал с этим файлом.
---
## Что стоит сделать перед коммитом
1. `git add mdexport/` — иначе всё сломается на свежем клоне.
2. Просмотреть `git diff --cached` и `git diff` — там 34 файла изменений плюс 8095 удалённых строк.
3. Прогнать `.venv\Scripts\python.exe -m pytest -q` ещё раз после `git add`.
4. Собрать exe одним из `build-exe*.bat` — ни один из билд-скриптов в ходе аудита не проверялся, а `pyproject.toml` и состав пакетов поменялись.
AI-Docs_WriteHuman/docs/archimate.md
+662
View File
@@ -0,0 +1,662 @@
# ArchiMate 3.2: гайд по генерации схем (PlantUML + md2gost)
Учебный гайд по **правильной генерации** диаграмм ArchiMate® 3.2 в PlantUML для отчётов md2gost.
Язык — **только 3.2** (документ C226). ArchiMate 4 не используется.
ArchiMate® — зарегистрированный товарный знак The Open Group. Текст гайда — учебный пересказ корпуса PDF и документации PlantUML, **не** копия спецификации.
## Содержание
1. [Как рисовать в md2gost](#1-как-рисовать-в-md2gost)
2. [Каркас языка 3.2](#2-каркас-языка-32)
3. [Каталог элементов → макросы PlantUML](#3-каталог-элементов--макросы-plantuml)
4. [Связи](#4-связи)
5. [Что с чем связывать](#5-что-с-чем-связывать)
6. [Viewpoints](#6-viewpoints)
7. [Синтаксис PlantUML](#7-синтаксис-plantuml)
8. [Чеклист для ИИ](#8-чеклист-для-ии)
9. [Готовые шаблоны](#9-готовые-шаблоны)
10. [Антипаттерны](#10-антипаттерны)
11. [Источники и границы корпуса](#11-источники-и-границы-корпуса)
---
## 1. Как рисовать в md2gost
Оградка схемы: `` ```uml-archimate `` или `` ```archimate ``.
В теле пишите **только макросы** Archimate-PlantUML. Без `@startuml`, без `@enduml`, без `!include` — схема `archimate` добавит их сама.
````markdown
%arch1 Слоистая архитектура портала +landscape
```uml-archimate
LAYOUT_TOP_DOWN()
Business_Actor(student, "Студент")
Business_Process(enroll, "Подача заявки")
Application_Service(portalSvc, "Портал заявок")
Application_Component(portal, "Web-портал")
Rel_Assignment(student, enroll)
Rel_Serving(portalSvc, enroll)
Rel_Realization(portal, portalSvc)
```
````
| Флаг у `%подписи` | Смысл |
|-------------------|--------|
| `+landscape` | Альбомная страница под широкий рисунок |
| `+listing` | Рядом показать исходник диаграммы |
Широкие Layered / Application Cooperation почти всегда с `+landscape`.
---
## 2. Каркас языка 3.2
### 2.1. Модель, концепт, элемент, связь
По sample C226 (§2–3):
- **Model** — набор концептов.
- **Concept** — либо **element**, либо **relationship**.
- **Element** — behavior, structure, motivation или composite (абстрактные классы; в модели не рисуются сами по себе).
- **Relationship** — связь source → target; класс: structural / dependency / dynamic / other.
- **Relationship connector (Junction)** — соединяет две или более связи **одного** типа.
Язык намеренно мал: «80 % практических случаев», без попытки покрыть всех пользователей сразу (§3.1).
### 2.2. Три core-слоя
| Слой | Что показывает |
|------|----------------|
| **Business** | Бизнес-сервисы для клиентов; процессы и акторы, которые их реализуют |
| **Application** | Прикладные сервисы и приложения, поддерживающие бизнес |
| **Technology** | ИТ и OT: обработка, хранение, сети; также физика (сооружения, оборудование, материалы, распределительные сети) |
Структура моделей на слоях похожа: те же виды элементов и связей, разная природа и гранулярность.
### 2.3. Аспекты (подлежащее — сказуемое — дополнение)
| Аспект | Роль | Примеры |
|--------|------|---------|
| **Active structure** | Кто/что действует | Actor, Role, Component, Node, Device |
| **Behavior** | Что делается | Process, Function, Interaction, Service, Event |
| **Passive structure** | Над чем работают | Business Object, Data Object, Artifact, Material |
| **Motivation** | Зачем | Stakeholder, Driver, Goal, Requirement… |
| **Composite** | Группировка / место | Grouping, Location, Product |
На листах Виерды (не стандарт Open Group): синий = активная структура, жёлтый = поведение, зелёный = пассивная. **Официальный ArchiMate бесцветен**; цвета — соглашение инструментов (в PlantUML — палитры слоёв `#Business`, `#Application`, …).
### 2.4. Full framework
К core добавляются (van den Berg §2.4 / full framework C226):
- слой **Strategy**;
- слой **Implementation & Migration**;
- аспект **Motivation**.
### 2.5. Два главных межслойных моста (§3.3)
1. **Serving** (раньше *used by*): сервис (или элемент) **предоставляет функциональность** другому. Сервис нижнего/соседнего слоя обслуживает потребителя. Сервис может обслуживать и элемент **того же** слоя.
2. **Realization**: более конкретное (часто ниже) **реализует** более абстрактное (часто выше): например приложение реализует прикладной сервис, сервис/процесс реализует требование или capability.
Каноническая цепочка внутри слоя:
```text
Active structure —Assignment→ internal behavior (Process/Function)
internal behavior —Realization→ Service (external behavior)
Service —Serving→ consumer (Role / Process / Component …)
behavior —Access→ passive structure
```
---
## 3. Каталог элементов → макросы PlantUML
Определения — **N221** (Reference Cards). Макросы — Archimate-PlantUML 3.2.1.
Формат: `Category_ElementName(alias, "Подпись")`.
Alias — латиница (`student`, `crm`). Не используйте `end`, `start`, `group` как alias.
### 3.1. Motivation
| Элемент | Макрос | Определение (N221) |
|---------|--------|-------------------|
| Stakeholder | `Motivation_Stakeholder` | Роль индивида, команды или организации, заинтересованной в эффектах архитектуры |
| Driver | `Motivation_Driver` | Внешнее/внутреннее условие, побуждающее задать цели и изменения |
| Assessment | `Motivation_Assessment` | Результат анализа положения дел относительно driver |
| Goal | `Motivation_Goal` | Высокоуровневое намерение / желаемое конечное состояние |
| Outcome | `Motivation_Outcome` | Конечный результат / эффект некоторого положения дел |
| Principle | `Motivation_Principle` | Общее свойство, применимое к любой системе в контексте |
| Requirement | `Motivation_Requirement` | Потребность: свойство конкретной системы в архитектуре |
| Constraint | `Motivation_Constraint` | Ограничение на архитектуру, реализацию или процесс внедрения |
| Meaning | `Motivation_Meaning` | Знание/интерпретация концепта в контексте |
| Value | `Motivation_Value` | Относительная ценность / полезность концепта |
### 3.2. Strategy
| Элемент | Макрос | Определение (N221) |
|---------|--------|-------------------|
| Resource | `Strategy_Resource` | Актив, которым владеют или управляют |
| Capability | `Strategy_Capability` | Способность, которой обладает активная структура |
| Value Stream | `Strategy_ValueStream` | Последовательность активностей, создающая результат для клиента/стейкхолдера |
| Course of Action | `Strategy_CourseOfAction` | Подход/план настройки capabilities и resources для достижения цели |
### 3.3. Business
| Элемент | Макрос | Аспект | Определение (N221) |
|---------|--------|--------|-------------------|
| Business Actor | `Business_Actor` | Active | Сущность, способная выполнять поведение |
| Business Role | `Business_Role` | Active | Ответственность за поведение; роль актора |
| Business Collaboration | `Business_Collaboration` | Active | Агрегат ≥2 внутренних active structure для коллективного поведения |
| Business Interface | `Business_Interface` | Active | Точка доступа, где бизнес-сервис доступен среде |
| Business Process | `Business_Process` | Behavior | Последовательность бизнес-поведения к конкретному результату |
| Business Function | `Business_Function` | Behavior | Набор поведения по критериям (ресурсы/компетенции) |
| Business Interaction | `Business_Interaction` | Behavior | Коллективное поведение ≥2 акторов/ролей/коллабораций |
| Business Event | `Business_Event` | Behavior | Изменение состояния на бизнес-уровне |
| Business Service | `Business_Service` | Behavior | Явно определённое поведение, доступное среде |
| Business Object | `Business_Object` | Passive | Концепт предметной области |
| Contract | `Business_Contract` | Passive | Соглашение провайдер–потребитель (права/обязанности, параметры) |
| Representation | `Business_Representation` | Passive | Воспринимаемая форма информации бизнес-объекта |
| Product | `Business_Product` | Composite | Согласованный набор сервисов/пассивных элементов + contract |
### 3.4. Application
| Элемент | Макрос | Аспект | Определение (N221) |
|---------|--------|--------|-------------------|
| Application Component | `Application_Component` | Active | Инкапсуляция прикладной функциональности, модульная и заменяемая |
| Application Collaboration | `Application_Collaboration` | Active | Агрегат ≥2 application internal active structure |
| Application Interface | `Application_Interface` | Active | Точка доступа к application services |
| Application Function | `Application_Function` | Behavior | Автоматизированное поведение компонента |
| Application Interaction | `Application_Interaction` | Behavior | Коллективное поведение ≥2 компонентов |
| Application Process | `Application_Process` | Behavior | Последовательность прикладного поведения к результату |
| Application Event | `Application_Event` | Behavior | Изменение состояния приложения |
| Application Service | `Application_Service` | Behavior | Явно определённое внешнее прикладное поведение |
| Data Object | `Application_DataObject` | Passive | Данные, структурированные для обработки |
### 3.5. Technology (+ Physical в гл. Technology 3.2)
| Элемент | Макрос | Определение (N221) |
|---------|--------|-------------------|
| Node | `Technology_Node` | Вычислительный/физический ресурс, хостящий другие ресурсы |
| Device | `Technology_Device` | Физический ИТ-ресурс для хранения/исполнения ПО и артефактов |
| System Software | `Technology_SystemSoftware` | ПО среды исполнения/хранения |
| Technology Collaboration | `Technology_Collaboration` | Агрегат ≥2 technology internal active structure |
| Technology Interface | `Technology_Interface` | Точка доступа к technology services |
| Path | `Technology_Path` | Связь между ≥2 technology internal active structure для обмена |
| Communication Network | `Technology_CommunicationNetwork` | Структуры/поведение для передачи данных |
| Technology Function | `Technology_Function` | Набор технологического поведения |
| Technology Process | `Technology_Process` | Последовательность технологического поведения |
| Technology Interaction | `Technology_Interaction` | Коллективное technology-поведение |
| Technology Event | `Technology_Event` | Изменение технологического состояния |
| Technology Service | `Technology_Service` | Явно определённое внешнее technology-поведение |
| Artifact | `Technology_Artifact` | Данные/файл, используемый или порождаемый разработкой/эксплуатацией |
| Equipment | `Physical_Equipment` | Физические машины/инструменты для материи |
| Facility | `Physical_Facility` | Физическая структура или окружение |
| Distribution Network | `Physical_DistributionNetwork` | Физическая сеть транспортировки материи/энергии |
| Material | `Physical_Material` | Осязаемая материя или энергия |
В 3.2 Device / System Software / Facility / Equipment — **не** подтипы Node, а technology internal active structure с composition/aggregation к Node (changelog C226).
### 3.6. Implementation & Migration
| Элемент | Макрос | Определение (N221) |
|---------|--------|-------------------|
| Work Package | `Implementation_WorkPackage` | Серия действий с результатом в сроках и ресурсах |
| Deliverable | `Implementation_Deliverable` | Точно определённый результат work package |
| Implementation Event | `Implementation_Event` | Изменение состояния, связанное с внедрением/миграцией |
| Plateau | `Implementation_Plateau` | Относительно стабильное состояние архитектуры на период |
| Gap | `Implementation_Gap` | Различие между двумя plateaus |
### 3.7. Composite и Junction
| Элемент | Макрос | Определение (N221) |
|---------|--------|-------------------|
| Grouping | `Grouping` / `Other_Grouping` / `Group` | Агрегирует/композирует концепты по общему признаку |
| Location | `Other_Location` / `Business_Location` | Место, где расположены или выполняются концепты |
| And Junction | `Junction_And` | Логическое И для связей одного типа |
| Or Junction | `Junction_Or` | Логическое ИЛИ для связей одного типа |
Grouping и Junction допустимы **в любом** viewpoint (спецификация).
### 3.8. Когда какой элемент поведения
| Нужно | Берите |
|-------|--------|
| Последовательность шагов к результату | `*_Process` |
| Группа поведения «изнутри» по компетенциям/ресурсам | `*_Function` |
| Поведение коллаборации (≥2 участников) | `*_Interaction` |
| Внешне видимое поведение (чёрный ящик) | `*_Service` |
| Момент / смена состояния | `*_Event` |
**Не смешивайте слои:** `Business_Process` ≠ `Application_Process` ≠ `Technology_Process`. Слой задаётся типом элемента, не подписью.
---
## 4. Связи
### 4.1. Одиннадцать типов (N221) + PlantUML
| Тип | Класс | Смысл (N221) | Макрос | Нотация PlantUML |
|-----|-------|--------------|--------|------------------|
| Composition | Structural | Элемент **состоит из** других; часть не существует без целого | `Rel_Composition` | `*--` |
| Aggregation | Structural | Элемент **объединяет** другие; части могут жить отдельно | `Rel_Aggregation` | `o--` |
| Assignment | Structural | Ответственность / выполнение поведения / хранение / исполнение | `Rel_Assignment` | `@-->>` |
| Realization | Structural | Критическая роль в создании/достижении более абстрактного | `Rel_Realization` | `~~|>` |
| Serving | Dependency | Предоставляет функциональность другому | `Rel_Serving` | `-->` |
| Access | Dependency | Поведение/active structure наблюдает или действует на passive | `Rel_Access` / `_r` / `_w` / `_rw` | `~~` / `<-~` / `~->` / `<~~>` |
| Influence | Dependency | Влияет на реализацию/достижение motivation-элемента (`+/-`) | `Rel_Influence` | `..>` |
| Triggering | Dynamic | Временная/причинная активация | `Rel_Triggering` | `-->>` |
| Flow | Dynamic | Передача чего-либо | `Rel_Flow` | `..>>` |
| Specialization | Other | Является разновидностью | `Rel_Specialization` | `--|>` |
| Association | Other | Неспецифичная связь (или нет другого типа) | `Rel_Association` / `_dir` | `--` / `--\` |
| Junction | Connector | Соединяет связи **одного** типа | `Junction_And` / `Junction_Or` | circle |
Направление на схеме: `Rel_Type_Up` / `_Down` / `_Left` / `_Right` (например `Rel_Serving_Up(svc, proc)`).
### 4.2. Направления (частые ошибки)
| Связь | Откуда → куда |
|-------|----------------|
| **Serving** | Поставщик (часто Service) → **потребитель** |
| **Realization** | Более конкретное → более абстрактное |
| **Composition / Aggregation** | Целое → часть |
| **Assignment** | Active structure → behavior (или ресурс хранения → artifact) |
| **Access** | Behavior (или active) → **passive**; тип: read / write / read-write |
| **Triggering** | Предшественник → следующий |
| **Flow** | Источник передачи → приёмник |
| **Influence** | Влияющий → motivation-элемент (сила `++`/`+`/`0`/`-`/`--` в подписи) |
| **Specialization** | Специализация → общий тип |
На листах: realization — «вверх» по абстракции; serving — к тому, кого обслуживают. Access всегда к объекту, независимо от отрисовки стрелки.
### 4.3. Правила с листов (метамодель ядра)
- Любой элемент может **compose/aggregate** элементы **того же класса** (на обзорных диаграммах часто не рисуют).
- Внутренние поведения одного слоя могут compose/aggregate друг друга (Function агрегирует Process).
- **Association** формально возможна между любыми классами — но на схеме используйте её только когда нет более точного типа.
- Collaboration ведёт себя как соответствующий internal active structure.
- Stakeholder — Association с любым элементом; элементы мотивации (кроме Stakeholder) — Influence друг на друга.
### 4.4. Чего нет в корпусе
Полная **Appendix B** (матрица всех допустимых пар и derivation) в sample PDF **обрезана**. Ниже — практические цепочки из §3.3, N221, листов и типичных viewpoint’ов. Не выдавайте их за полную нормативную матрицу B.
---
## 5. Что с чем связывать
### 5.1. Канонические цепочки
```text
# Внутри слоя
Business_Actor/Role Rel_Assignment Business_Process/Function
Business_Process Rel_Realization Business_Service
Business_Process Rel_Access_* Business_Object
Business_Event Rel_Triggering Business_Process
Application_Component Rel_Assignment Application_Function/Process
Application_Function Rel_Realization Application_Service
Application_Service Rel_Serving Business_Process/Role
Application_Component Rel_Access_* Application_DataObject
Application_Component Rel_Composition Application_Component
Technology_Node Rel_Composition Technology_Device / SystemSoftware
Technology_* Rel_Assignment Technology_Function/Process
Technology_Function Rel_Realization Technology_Service
Technology_Service Rel_Serving Application_Component
Technology_Artifact Rel_Realization Application_DataObject
Application_DataObject Rel_Realization Business_Object
# Стратегия / мотивация
Business_Process / Application_Service Rel_Realization Strategy_Capability
Application_Service / Component Rel_Realization Motivation_Requirement
Motivation_Driver Rel_Association Motivation_Stakeholder
Motivation_Assessment Rel_Association Motivation_Driver
Motivation_Goal Rel_Realization Motivation_Outcome
Motivation_Requirement Rel_Specialization Motivation_Constraint # или наоборот по смыслу «ограничение как вид требования» — лучше Constraint отдельно + Influence/Association
# Миграция
Implementation_WorkPackage Rel_Realization / Aggregation Implementation_Deliverable
Implementation_Plateau Rel_Aggregation core elements
Implementation_Gap Rel_Association between plateaus
```
### 5.2. Запреты для генерации
1. Не `Rel_Assignment` от Data Object / Business Object к процессу.
2. Не `Rel_Realization` от Component сразу к Process — нужен Function/Process того же слоя, затем Realization к Service.
3. Не `Rel_Serving` «потребитель → сервис» (перевёрнуто).
4. Не подменять Access потоком Flow «потому что данные».
5. Не рисовать `Business_Process` вместо `Application_Process`, если исполнитель — компонент.
6. Не ставить Association на все рёбра «на всякий случай».
7. Не считать Device подтипом Node без composition/aggregation (3.2).
---
## 6. Viewpoints
**Один рисунок = один viewpoint.** Не сваливайте мотивацию, бизнес, приложения и ЦОД на один холст без нужды (Layered — исключение, но всё равно ограничивайте число элементов).
Имена — из оглавления sample C226, Appendix C:
### 6.1. Basic (C.1)
| Viewpoint | Фокус | Типичные элементы |
|-----------|-------|-------------------|
| Organization | Структура орг. единиц | Actor, Role, Collaboration, Location, Interface |
| Application Structure | Внутренняя структура приложений | Component, Collaboration, Interface, Data Object |
| Information Structure | Данные/информация | Business Object, Representation, Data Object, Artifact, Meaning |
| Technology | Инфраструктура | Node, Device, System Software, Network, Path, Artifact… |
| Layered | Обзор слоёв | Набор из Business + Application + Technology + serving/realization |
| Physical | Физический мир | Equipment, Facility, Distribution Network, Material + tech |
| Product | Ценность продукта | Product, Contract, Services, Interfaces |
| Application Usage | Приложения в бизнес-контексте | Process/Function/Service бизнес + application |
| Technology Usage | Технологии для приложений | Application + Technology services/nodes |
| Business Process Cooperation | Связь процессов | Processes, Events, Services, Roles, supporting apps |
| Application Cooperation | Связь приложений | Components, Services, Interfaces, Data, Flow/Serving |
| Service Realization | Как сервисы реализованы | Service ← Process/Function ← Active structure |
| Implementation and Deployment | Развёртывание | Application + Artifact + Node/Device |
### 6.2. Motivation (C.2)
Stakeholder · Goal Realization · Requirements Realization · Motivation — Driver/Assessment/Goal/Outcome/Principle/Requirement/Constraint/Value/Meaning и Realization/Influence к core.
### 6.3. Strategy (C.3)
Strategy · Capability Map · Value Stream · Outcome Realization · Resource Map.
### 6.4. Implementation & Migration (C.4)
Project · Migration · Implementation and Migration — Work Package, Deliverable, Plateau, Gap, Event.
### 6.5. Макет
- Организация / структура: `LAYOUT_TOP_DOWN()` или вложенность `{ }`.
- Процессы слева направо: `LAYOUT_LEFT_RIGHT()` + `Rel_*_Right`.
- Layered: бизнес сверху, technology снизу; serving вверх (`Rel_Serving_Up`), realization вверх к абстракции.
- Широкие схемы: `%id … +landscape`.
Пример композиции (van den Berg): сначала **Motivation viewpoint** (риски/цели), затем отдельные схемы процессов с **Junction** на ветвлениях восстановления.
---
## 7. Синтаксис PlantUML
Документация: [plantuml.com/archimate-diagram](https://plantuml.com/archimate-diagram). Stdlib: Archimate-PlantUML **3.2.1**.
### 7.1. Рекомендуемый путь (схема md2gost)
```text
LAYOUT_TOP_DOWN() ' или LAYOUT_LEFT_RIGHT()
Business_Actor(a, "Имя")
Application_Service(s, "Сервис")
Rel_Serving_Up(s, a)
```
Include и `@startuml` добавляет схема `archimate`.
### 7.2. Низкоуровневый keyword (без макросов)
Только в `` ```uml ``, если stdlib недоступен:
```plantuml
@startuml
archimate #Business "Подача заявки" as p <<business-process>>
archimate #Application "Портал" as c <<application-component>>
c --> p
@enduml
```
Sprites: `<<$archimate/business-process>>` или `jar:archimate/...`.
**Не смешивайте** макросы и сырой `archimate` на одной схеме.
### 7.3. Темы
```plantuml
!theme archimate-standard from <archimate/themes>
' archimate-alternate | saturated | lowsaturation | handwriting
```
### 7.4. Nesting и special shapes
```plantuml
Business_Product(prod, "Тариф") {
Business_Service(s1, "Подключение")
Business_Contract(c1, "Оферта")
}
```
Для special shapes (`$ARCH_SPECIAL_SHAPES`) у Service/Actor/Value/ValueStream при вложении: `$nest=%true()`.
### 7.5. Layout helpers
`Lay_U` / `Lay_D` / `Lay_L` / `Lay_R` — скрытые связи для выравнивания.
`LAYOUT_AS_SKETCH()` — черновик (не для финального ГОСТ-рисунка).
### 7.6. Sequence с ArchiMate
Только если явно просят sequence: `!global $ARCH_SEQUENCE_SUPPORT = %true()` до include. Это **не** замена viewpoint.
### 7.7. List sprites
```plantuml
@startuml
listsprite
@enduml
```
---
## 8. Чеклист для ИИ
1. Версия языка: **ArchiMate 3.2**; макросы слоя (`Business_*`, `Application_*`, …).
2. Оградка `` ```uml-archimate ``; без `@startuml` / `!include`.
3. Выбрать **один** viewpoint; 8–18 элементов на рисунок.
4. Сначала все элементы, потом все `Rel_*`.
5. Alias латиницей; подписи по-русски в кавычках; длинные имена с `\n`.
6. Serving от сервиса к потребителю; Realization от конкретного к абстрактному.
7. Поведение того же слоя, что и исполнитель (Assignment).
8. Не UML class/component, не C4 `Person`, не BPMN `XOR`, не mxgraph.
9. Не Association «по умолчанию».
10. Для отчёта: `%id Название` (+ `+landscape` если широко).
---
## 9. Готовые шаблоны
Тела для `` ```uml-archimate `` (без обёртки).
### 9.1. Organization
```plantuml
LAYOUT_TOP_DOWN()
Business_Actor(uni, "Университет") {
Business_Actor(dean, "Деканат")
Business_Actor(it, "Управление ИТ")
}
Business_Role(student, "Студент")
Business_Role(clerk, "Методист")
Rel_Assignment(dean, clerk)
Rel_Assignment(uni, student)
```
### 9.2. Service Realization
```plantuml
LAYOUT_TOP_DOWN()
Business_Role(applicant, "Абитуриент")
Business_Process(apply, "Подача заявления")
Business_Service(applySvc, "Приём заявлений")
Application_Service(webSvc, "Веб-приёмная")
Application_Component(lk, "Личный кабинет")
Application_Function(submitFn, "Отправка формы")
Rel_Assignment(applicant, apply)
Rel_Realization(apply, applySvc)
Rel_Serving(webSvc, apply)
Rel_Assignment(lk, submitFn)
Rel_Realization(submitFn, webSvc)
```
### 9.3. Application Cooperation
```plantuml
LAYOUT_LEFT_RIGHT()
Application_Component(crm, "CRM")
Application_Component(billing, "Биллинг")
Application_Service(crmApi, "API клиентов")
Application_DataObject(client, "Карточка клиента")
Rel_Realization(crm, crmApi)
Rel_Serving(crmApi, billing)
Rel_Access_rw(crm, client)
Rel_Access_r(billing, client)
Rel_Flow(crm, billing, "событие оплаты")
```
### 9.4. Layered
```plantuml
LAYOUT_TOP_DOWN()
Business_Process(sale, "Оформление заказа")
Business_Object(order, "Заказ")
Application_Service(shopSvc, "Интернет-магазин")
Application_Component(shop, "ShopApp")
Technology_Service(dbSvc, "СУБД")
Technology_Node(dbHost, "DB Host")
Technology_SystemSoftware(pg, "PostgreSQL")
Rel_Access_w(sale, order)
Rel_Serving_Up(shopSvc, sale)
Rel_Realization(shop, shopSvc)
Rel_Serving_Up(dbSvc, shop)
Rel_Assignment(dbHost, dbSvc)
Rel_Composition(dbHost, pg)
```
### 9.5. Motivation / Requirements Realization
```plantuml
LAYOUT_TOP_DOWN()
Motivation_Stakeholder(rector, "Ректор")
Motivation_Driver(comp, "Конкуренция вузов")
Motivation_Goal(digital, "Цифровизация приёма")
Motivation_Requirement(online, "Заявление онлайн 24/7")
Motivation_Constraint(152fz, "152-ФЗ")
Application_Service(portal, "Портал абитуриента")
Rel_Association(rector, comp)
Rel_Association(comp, digital)
Rel_Realization(online, digital)
Rel_Influence(152fz, online, "-")
Rel_Realization(portal, online)
```
### 9.6. Implementation & Migration
```plantuml
LAYOUT_LEFT_RIGHT()
Implementation_Plateau(asIs, "AS-IS 2025")
Implementation_Plateau(toBe, "TO-BE 2026")
Implementation_Gap(gap1, "Нет единого ЛК")
Implementation_WorkPackage(wp, "Проект Единый ЛК")
Implementation_Deliverable(d1, "Релиз 1.0")
Implementation_Event(goLive, "Go-Live")
Rel_Association(gap1, asIs)
Rel_Association(gap1, toBe)
Rel_Realization(wp, d1)
Rel_Triggering(d1, goLive)
Rel_Triggering(goLive, toBe)
```
### 9.7. Technology Usage
```plantuml
LAYOUT_TOP_DOWN()
Application_Component(api, "API Gateway")
Technology_Node(k8s, "Kubernetes")
Technology_Device(node1, "Worker x86")
Technology_SystemSoftware(os, "Linux")
Technology_CommunicationNetwork(net, "Cluster CNI")
Technology_Artifact(image, "api:1.2.img")
Rel_Serving_Up(k8s, api)
Rel_Composition(k8s, node1)
Rel_Composition(node1, os)
Rel_Association(node1, net)
Rel_Assignment(node1, image)
```
### 9.8. Process с Junction (в духе van den Berg)
```plantuml
LAYOUT_LEFT_RIGHT()
Business_Event(incident, "Инцидент")
Business_Process(triage, "Триаж")
Junction_Or(j1, "")
Business_Process(restore, "Восстановление КФ")
Business_Process(investigate, "Расследование")
Business_Process(close, "Закрытие")
Rel_Triggering(incident, triage)
Rel_Triggering(triage, j1)
Rel_Triggering(j1, restore)
Rel_Triggering(j1, investigate)
Rel_Triggering(restore, close)
Rel_Triggering(investigate, close)
```
---
## 10. Антипаттерны
| Плохо | Почему | Как надо |
|-------|--------|----------|
| Все связи `Rel_Association` | Теряется семантика | Serving / Realization / Assignment / Access |
| `Application_Component` вместо `Business_Actor` | Разные аспекты и слои | Actor/Role для людей/орг. единиц |
| Business Process «внутри» компонента без Assignment | Слои смешаны | Process на бизнес-слое; Serving от Application Service |
| Serving от Role к Service | Направление наоборот | Service → Role/Process |
| Realization Component → Process | Пропущен внутренний behavior | Component → Function → Service |
| Flow вместо Access к Data Object | Flow — передача, Access — работа с объектом | `Rel_Access_r/w/rw` |
| Один Layered на 40+ элементов | Нечитаемо | Несколько viewpoint’ов |
| C4 `Person` / UML class в archimate-блоке | Другой язык | Только макросы ArchiMate |
| Generic «Process» без слоя | В 3.2 слоя обязательны | `Business_Process` / `Application_Process` / … |
---
## 11. Источники и границы корпуса
### Норматив (при конфликте — сверху вниз)
1. **n221p.pdf** — ArchiMate 3.2 Reference Cards (N221): определения элементов и связей.
2. **978940180955C_SMPL.pdf** (+ дубль SMPL-1) — sample C226: гл. 1–2, начало гл. 3, оглавление (в т.ч. список viewpoints Appendix C).
3. **archimate-sheets-ru-20230805-s.pdf** — листы метамодели 3.2 (Виерда / Ефремов): прямые связи, цвета аспектов на листах. Описания элементов на листах **не** от Open Group — для формулировок «что такое X» побеждает N221.
### Синтаксис рисунка
- [plantuml.com/archimate-diagram](https://plantuml.com/archimate-diagram)
- Stdlib Archimate-PlantUML 3.2.1 (`!include <archimate/Archimate>`)
### Примеры композиции (не словарь языка)
- hospital ZiRA preview (inkijkexemplaar) — reference architecture / C226.
- **vandenBerg_MA_EEMCS.pdf** — §2.4 framework, motivational viewpoint, Junction в процессах BCM/DR.
### Не правила ArchiMate
- Article_37 (FEM), paper_41 (OntoUML/COVO), FASD (UML атак), 419 (единое окно), **2659430** (Packt Practical Cybersecurity Architecture — процесс кибер-архитектуры, не спецификация 3.2).
### Ограничения
- Полная Appendix B в sample отсутствует — матрица пар здесь практическая, не нормативная таблица B.5.
- PDF спецификации в git не хранятся.
- Старый PlantUML/Kroki без stdlib 3.2: fallback — `` ```uml `` + keyword `archimate`.
- Пользовательский `md2gost.schemes.json`: встроенные схемы с `author: md2gost` синхронизируются с бандлом; свои правки (другой author) не затираются.
---
См. также: [schemes.md](schemes.md), меню **Шаблоны UML**, **Справка → Промпт для ИИ** (схема `archimate`).
AI-Docs_WriteHuman/docs/audit-report.md
+243
View File
@@ -0,0 +1,243 @@
# Отчёт по аудиту и оптимизации
Проведён 9-10 сентября 2026. Незакрытые задачи — в [TODO.md](TODO.md), команды ручной чистки git — в [git-cleanup.md](git-cleanup.md).
**Ничего не закоммичено.** Всё лежит в staging и рабочем дереве под ревью.
## Итог одной таблицей
| | Было | Стало |
|---|---|---|
| Замер страницы из 5 абзацев | 80.06 мс | 18.08 мс |
| Конструирований `Font` за проход | 19 | 0 |
| Вызовов `get_text_width` за проход | 814 | 114 |
| Конвертация формулы | 13.29 мс | 0.66 мс |
| PlantUML, 4 диаграммы, PNG | 4.99 с | 1.25 с |
| PlantUML, 4 диаграммы, SVG | 9.02 с | 2.33 с |
| Запусков JVM на документ | N (2N в SVG) | 1 (2 в SVG) |
| Сквозная конвертация документа | — | на 10-23% быстрее |
| Тесты | 54 passed | 320 passed, 174 subtests |
Объём изменений: 34 файла правок (+1552 / −698), плюс 34 файла удалений (−8095 строк).
---
## 1. Исправлено три бага вывода
Работа шла строго по TDD: сначала три падающих теста, прогон с 9 падениями по ожидаемым причинам, затем правки. Каждый фикс привязан к пункту методички МИРЭА (`docs/reference/method-mirea-2022.txt`).
### Гиперссылка дублировала свой текст
`md2gost/renderable/paragraph.py`, строка 44. В `Link.add_run` цикл по сегментам присваивал `docx_run.text = text` вместо `part`, поэтому ссылка с дефисом выводилась полным текстом столько раз, сколько в ней сегментов.
Красный тест показал это нагляднее всего на интервале: `['100', '150'] != ['100-150', '100-150']`. На сложном слове: `'вопервых' != 'во-первыхво-первых'`.
Опечатка при копировании из `Paragraph.add_run`, где на строке 104 тот же цикл написан правильно.
Обоснование: строки 373-376 методички — дефис не отделяется пробелами и используется в сложных словах («во-первых», «физико-математический») и интервалах («100-150 Мб»), поэтому слово не должно рваться при переносе. Ради этого и вставляется отдельный элемент `w:noBreakHyphen` вместо текстового дефиса.
### Курсив в подсветке синтаксиса не доезжал до XML
`md2gost/renderable/listing.py`, строка 36. Выражение `style["italic"] in style or None` проверяло, есть ли значение `True`/`False` среди **ключей** словаря стиля. Всегда ложно, курсив не применялся никогда.
Здесь пришлось разбираться, что вообще считать правильным поведением. Табл. 4.1 методички (строки 716-721) требует для содержимого листинга `Courier New / Начертание Обычный / 10 пт / Цвет Авто (чёрный)`. Стили в `style_config.py:303-314` этому соответствуют, но `DocxParagraphPygmentsFormatter` перекрывает их на уровне run'а, навешивая полужирный и цвет. То есть подсветка как таковая противоречит методичке, а сломанный курсив лишь случайно оказывался ближе к требованию.
Решение в два шага: выражение исправлено на `style.get("italic") or None`, чтобы флаг делал то, что обещает, и добавлено правило `listing.syntax_highlighting` в checker — предупреждение по умолчанию, ошибка под `--strict`. Флаг выключен по умолчанию, так что это осознанное отклонение, но пользователь узнаёт о нём из отчёта, а не из замечаний преподавателя.
Заодно добавлен регрессионный страж: при выключенном флаге ни один run в стиле `Code` не должен задавать `w:b`, `w:i` или `w:color`.
### Пустой заголовок ронял парсер
`md2gost/extended_markdown/heading.py`, строка 23. `inline_body[0] == "*"` давал `IndexError` на строке `#` без текста. Заменено на `startswith`.
Плюс правило `heading.empty` в checker'е: пустой заголовок дал бы пронумерованный безымянный раздел в автособираемом содержании. Обоснование — строка 156 методички: «разделы, подразделы, пункты имеют заголовки, четко и кратко отражающие их содержание».
Побочно выяснилось расхождение в постановке: я просил проверить форму `#*`, но такая строка регуляркой заголовка вообще не матчится — после `#` обязателен пробел или конец строки. Заголовком является только `# *`, эта форма и покрыта тестом.
---
## 2. Горячий путь измерения текста ускорен в 4.4 раза
### Кэш объектов `Font`
Замер показал, что один `Font()` конструируется 2.62 мс: открывает FreeType `Face`, грузит `ImageFont.truetype` и аллоцирует PIL-канвас 1000×1000. При этом он создавался дважды за вызов `calculate_height` плюс по разу на каждый run.
Добавлен модульный `_get_font(name, bold, italic, size_pt)` под `lru_cache(maxsize=256)`, все три места конструирования переведены на него. Сам класс `Font` оставлен публичным — существующие тесты создают его напрямую.
### Скрытая мина в `is_mono`
Попутно нашлось то, чего в плане не было. Ветка `get_text_width` для моноширинных шрифтов читала `self._face.glyph.advance.x` — то есть тот глиф, который последним оставил в слоте `load_char`. Всегда оказывался `"m"`, потому что единственные вызовы `load_char` живут в `is_mono`. Значение было верным, но верным по случайности: любое постороннее обращение к face молча его сломало бы.
`is_mono` заменён на свойство `_metrics`, которое снимает и флаг моноширинности, и advance за один проход. Результат теперь не зависит от порядка обращений к слоту глифа. Есть тест, который долбит `load_char` посторонними символами и проверяет, что ширина не поехала.
### Квадратичный пересчёт ширины слова
`count_lines` пересчитывал ширину префикса слова после каждого символа, хотя результат читается только в ветке `if c == " "`. Вызов перенесён в две точки: на пробеле и один раз в конце каждого run.
Вторая точка — та, которую легко пропустить: слово может пересекать границу run'ов, а следующая итерация добавляет свежий слот в `word_parts_widths`, поэтому фрагмент нужно померить до этого.
Намеренно сохранено одно неочевидное поведение оригинала: `word_part` не сбрасывается после замера на пробеле, потому что исходный код сбрасывал его только внутри ветки `if any(word_parts_widths)`, и фрагмент нулевой ширины продолжал накапливаться через пробел.
### Синглтон XSLT
`md2gost/latex_math.py` парсил `mml2omml` с диска и компилировал `etree.XSLT` заново на каждую формулу. Вынесено в ленивый `_mml2omml_transform()`. Оставлено внутри `try`, чтобы битый или отсутствующий stylesheet по-прежнему давал тот же `ValueError` при каждом вызове.
### Как доказана эквивалентность
Не чтением кода. Пять эталонных тестовых файлов прогнаны до и после, verbose-вывод сдиффен построчно — идентичен. Плюс `tests/test_paragraph_sizer_cache.py` содержит дословные копии дооптимизационных `Font` и `count_lines` и сверяет с ними новый код на 158 случаях: одиночные и многорановые абзацы, разрыв слова на границе run'а, пустые run'ы, `w:noBreakHyphen`, смешанные полужирный с курсивом, кириллица, длинные неразрывные слова, сдвоенные и хвостовые пробелы, три ширины колонки, оба значения `is_mono`.
Чтобы убедиться, что корпус не вырожденный, замер в конце run'а был временно отключён — тесты упали в 5 местах.
---
## 3. Диаграммы: одна JVM на документ вместо одной на диаграмму
Перед проектированием было проверено фактическое поведение jar: PlantUML принимает много входных файлов за запуск, но только один флаг `-t<fmt>` (передача `-tpng -tsvg` молча отдаёт только SVG), а относительный `-o` резолвится от каталога каждого входного файла.
Отсюда конструкция: каждый источник получает свой подкаталог `NNNN/src.puml` с `-o out`. Это заодно решает коллизию двух источников, объявляющих `@startuml SameName`.
`DiagramFigure.__init__` регистрирует свой блок через `register_pending_diagram()`. Поскольку `Converter.convert()` полностью материализует `list(self.parser.parse())` до рендера, к моменту первого вызова `render_diagram()` очередь содержит весь документ. Первый вызов запускает одноразовый предпроход: готовит все источники, отбрасывает попавшие в кэш, остальные рендерит одной JVM.
Всё, что упало в предпроходе, остаётся промахом кэша и идёт обычным путём, так что цепочка PlantUML jar → локальный Kroki → удалённый Kroki и режимы `--diagram-fallback` не тронуты. `_render_plantuml_jar_one` теперь обёртка на одну задачу поверх того же батч-раннера, чтобы одиночный и пакетный пути не разъехались.
### Найденный попутно баг
Старый код писал `diagram.puml` и искал `diagram.{fmt}`. Любой источник с `@startuml SomeName` производил `SomeName.png`, считался провалом jar и молча уезжал на Kroki. Новая логика забирает то, что jar реально положил в выходной каталог этой диаграммы, и рендерит локально.
### Остальное по диаграммам
- Версия jar добавлена в ключ кэша: `PLANTUML_CACHE_PREFIX = f"plantuml-{PLANTUML_VERSION}\n"`. Раньше для plantuml префикс был пустой, и обновление jar отдавало старые PNG.
- `ensure_user_schemes()` убран из `render_diagram` — он мигрировал `md2gost.schemes.json` на каждую диаграмму. Безопасно: `load_merged_schemes()` его и так вызывает.
- Добавлен `shutdown_diagrams()`, закрывающий сессию Playwright, вызывается из существующего `finally` в `pipeline.convert()`.
- Graphviz для DFD теперь отдаёт PNG и SVG из одного процесса `dot`. Проверяет наличие и непустоту каждого выхода и повторяет недостающий формат старым путём, если сборка Graphviz не поддерживает пары.
Что проверено вживую: путь через jar целиком, включая батч, попадания в кэш, источники с `@startuml Name`, полный прогон `pipeline.convert()`. Graphviz тоже оказался установлен — комбинированный запуск реально произвёл оба файла, и на этом всплыло, что существующий DFD-тест тянулся мимо своего мока.
Что не проверено: локальный и удалённый Kroki (сервера нет, сетевых вызовов не делалось) — только моки; закрытие браузера в реальной mermaid-конвертации, потому что здешние тесты идут через QuickJS.
---
## 4. Двойная работа при рендере убрана
Все три места сначала обвешаны замерами, потом правлены. Доказательство для каждого — матрица из 4 документов на 7 наборов опций, 28 конвертаций, и побайтовое сравнение `word/document.xml` со снимком, снятым до любых правок. **28 из 28 идентичны.** В матрице `examples/example.md`, `examples/pis_custom.md`, синтетический стресс-документ (многостраничная дробящаяся таблица со слитыми ячейками, многостраничный листинг, три фигуры) и документ с альбомной ориентацией, каждый в режимах продолжений off / legacy / caption / soft, плюс ручное содержание, тип `PIS_custom` и авто-нумерация заголовков.
### Повторный рендер на границе страницы
`md2gost/renderer.py`. Раньше: отрендерить блок, померить первый `RenderedInfo`, и если не влезает — выбросить генератор и вызвать `render()` заново. Для таблицы или листинга это пересборка всего поддерева DOCX и повтор всех замеров.
Решение оказалось точнее, чем «разделить measure и emit», и это выяснилось именно замером. Повтор нужен только когда в `self._to_new_page` реально что-то стоит в очереди: отложенные фигуры вставляются первыми и двигают границу страницы, поэтому блок приходится раскладывать заново уже против оставленного ими состояния. Если очередь пуста, `_flush_to_new_screen()` — no-op, и повторный рендер строит то же поддерево против того же состояния.
Инструментирование показало, что **во всех срабатываниях на всей матрице очередь была пуста**, то есть второй проход был чистой потерей всегда. Триггером почти везде оказывались заголовки с `page_break_before` и одна фигура — ни разу таблица или листинг.
Условие дополнено проверкой `and self._to_new_page`. Структура render → measure → flush → re-render сохранена ровно для того случая, когда flush действительно меняет состояние.
### Подпись рисунка мерилась дважды
`md2gost/renderable/image.py`. Предложенный в плане `Image.estimate_height()` **не понадобился**: замер показал, что геометрия считается дёшево, а реальная стоимость сухого прохода — построение свежего `Caption` и прогон сайзера по нему. Поэтому подпись создаётся один раз и переиспользуется (сбрасывается в `set_number()`), а сама структура «сухой проход плюс настоящий рендер» не тронута. Именно поэтому вывод и смог остаться идентичным.
### Кэш замеров абзаца
Строки таблицы мерились до трёх раз. Теперь `_peek_row_height` и `_build_docx_row` идут через один мемоизированный замер, а выбрасываемый сухой `Caption` в `_start_block_height` убран — `render()` строит подпись один раз и передаёт её внутрь.
Общий хелпер `measure_paragraph()` в `paragraph_sizer.py` мемоизирует `calculate_height()` в разрезе владеющего renderable. Ключ собран так, чтобы это было безопасно в коде, решающем разрывы страниц:
- сериализованный XML измеряемого абзаца, а **не** идентичность объекта — правка между двумя вызовами тогда даёт промах кэша вместо устаревшей высоты;
- сериализованный `w:pPr` предшественника, а не он целиком — сайзер читает только `pPr`, а привязка `w:p` к телу документа заставляет lxml поднять на него объявления пространств имён, из-за чего полная сериализация выглядела бы как правка и молча промахивалась;
- ширина.
Сверх побайтового сравнения был прогнан «паранойяльный» режим, пересчитывающий значение на каждом попадании в кэш и сверяющий с сохранённым. Вся матрица прошла без единого устаревшего попадания. Строительные леса убраны, а `tests/test_paragraph_sizer_cache.py` получил семь регрессионных тестов: попадание равно свежему расчёту, инвалидация при правке текста и при правке интервалов, ширина и интервалы предшественника как части ключа, контракт приватной копии (вызывающий обнуляет `.before` на новой странице), случай с привязкой предшественника.
Попутно `page_break_before = False` перенесён из конца `render()` в `__init__`, чтобы оба замера подписи видели один и тот же абзац.
**Сквозное время конвертации упало на 10-23%** в зависимости от документа.
---
## 5. Удалено 6777 строк мёртвого кода
Больше моей исходной оценки в 5646. Для каждого файла искались импорты модуля, все top-level символы (извлечены через `ast`) и имя файла в `*.spec`, `*.bat`, `*.toml`, `.github/workflows/`, `tests/` и всех живых пакетах.
| Файл | Строк | Чем был |
|---|---|---|
| `mm3.py` | 2210 | Монолит + matplotlib-графики |
| `mm2.py` | 1551 | Монолитный сборщик DOCX, версия 2 |
| `main12.py` | 915 | Ранний `MarkdownGostDocument` |
| `font.py` | 860 | Своя реализация Font API |
| `parser.py` | 340 | Песочница на mistune |
| `asd.py` | 317 | Эксперимент со стилями ГОСТ |
| `mm5.py` | 284 | Прототип на mistune |
| `mm4.py` | 241 | Построчный прототип |
| `main.py` | 32 | Hello-world на python-docx |
| `_audit_tmp.py` | 27 | Разовый инспектор DOCX |
Проверены две ловушки: корневой `parser.py` мёртв, а `md2gost/parser_.py` живой и импортируется в `converter.py`; корневой `font.py` мёртв, а `md2gost/renderable/find_font.py` живой. Единственное вхождение `font` в импортах живых пакетов — `from docx.text.font import Font as DocxFont`, то есть сторонняя библиотека.
Мёртвый код внутри пакета: убраны `APPENDIX_RE` в `renderer.py` (дублировал константу из `label_pass.py`), `Listing._create_table`, `Converter._output_path`, no-op ветка `isinstance(r, Paragraph): pass` в `label_pass.py`, `_BrowserSession.render_svg()`, `_draw_purpose()` в `idef0.py`, плюс осиротевший `import os` в `paragraph_sizer.py`.
Две поправки к моему списку. **`gui.main()` оказался живым** — это консольный скрипт `md2gost-gui` в `pyproject.toml`, я ошибочно записал его в мёртвые; оставлен как есть. И комментарий у `Listing._create_table`, утверждавший, что метод держат ради тестов, не подтвердился: тесты ссылаются на модульную функцию `create_table`, а не на метод.
У `Converter._output_path` заодно убран и параметр конструктора — оставлять параметр, который класс игнорирует, смысла нет. `pipeline.py` был единственным вызывающим, его вызов переведён на именованные аргументы, чтобы остальные позиционные не съехали.
---
## 6. Гигиена репозитория
Снято с отслеживания, файлы остались на диске: `ReadMe.docx`, `md2gost/README.docx`, `tmp_*.docx`, `README.md1`, `examples/example_out.docx`, `examples/toc_*.docx`, `tests/_idef0_preview*`, `latex/mirea/Settings/FiraCode-Regular.otf` (220 КБ, ни одной ссылки в `.tex`), каталог `ad/`, `md2gost.user.json`.
Перенесено с сохранением истории: `_method_extract.txt` → `docs/reference/method-mirea-2022.txt`, `tests/extended_mardown/` → `tests/extended_markdown/`.
`md2gost.user.json` содержал реальные ФИО и группу. Убран из индекса, файл на диске остался рабочим, рядом появился `md2gost.user.json.example` с пустыми полями — структура сгенерирована из `UserProfile()` и `DocumentMetadata()`, так что совпадает с тем, что пишет `save_user_profile`.
### Зависимости
Легаси-секции `[tool.poetry]`, `poetry.lock` и `requirements.txt` удалены, канон — `[project]` плюс `uv.lock`.
При этом выяснилось, что `matplotlib` был объявлен **только** в удаляемой Poetry-секции, хотя импортируется в рантайме из `find_font.py` на всех платформах кроме Linux. Добавлено `matplotlib>=3.7; sys_platform != 'linux'` в `[project].dependencies`. Также поправлен `pywin32` — он был добавлен без маркера платформы, что ломало бы `pip install .` на Linux-CI, теперь `pywin32; sys_platform == 'win32'`.
Поле `readme` исправлено с `README.md` на фактическое `ReadMe.md` — расхождение регистра сломало бы сборку колеса на Linux.
### CI
`example-generator.yml` не запускался ни разу: триггер стоял на ветку `main`, а репозиторий на `master`. Исправлено в обоих триггерах. Артефакт грузился из `example.docx`, тогда как `default_output_path` кладёт файл рядом с входным — путь исправлен на `examples/example.docx`. Имя воркфлоу совпадало с `pytest.yml`, переименовано в `Example document`. Обновлены `upload-artifact@v3` → `v4`, `checkout@v3` → `v4`, `setup-python@v3` → `v5`, добавлен `apt-get update` перед установкой шрифтов.
### Тесты
Два метода с именем `test_count_lines_courier7` затирали друг друга — второй переименован, расшадоуенный первый **проходит**, латентного бага не вскрылось. Голые `return` в двух win32-тестах `test_pipeline.py` заменены на `@pytest.mark.skipif` (раньше они проходили без единой проверки). Опечатка в имени каталога `extended_mardown` исправлена.
Кстати про нумерацию: `test_count_lines_courier7` — это индекс 7 в серии от `courier1` до `courier10`, а не размер 7 пт. Третьего размера шрифта не существует, есть только 10 в `style_config` и 12 в фикстуре и калибровке.
---
## 7. Дедупликация сиблинг-конвертеров
`md2latex/emitter.py` и `md2fodt/emitter.py` содержали примерно 150-200 строк почти идентичного обхода AST: диспетчер блоков, инлайн-обходчик, детектор строк библиографии, машина состояний `pending_caption`, словарь русских подписей ссылок.
Создан отдельный верхнеуровневый пакет `mdexport` — внутрь `md2gost` его класть было нельзя, а размещение в одном из экспортёров сделало бы один бэкенд зависимым от другого. Три модуля:
- `blocks.py` — `walk_blocks`, `walk_paragraph`, ABC `BlockVisitor`, кортеж отложенной подписи и `take_caption()`, детектор строк библиографии, парсинг заголовка картинки `%id Подпись`, `is_contents_heading`
- `inline.py` — `render_inline`, ABC `InlineRenderer`, таблица русских названий ссылок
- `labels.py` — `sanitize_label`, параметризованный разделителем: `:` для LaTeX, `-` для XML `NCName`
`escape_text` остался в бэкендах — там разные задачи, карта символов LaTeX против `saxutils` для XML.
Эмиттеры сократились на 119 строк, сам общий пакет занял 309, из которых около 120 — новый интерфейсный каркас: объявления абстрактных методов, докстринги, реэкспорты. По суммарному LOC выигрыш скромный, реальный смысл в том, что перечень типов узлов и порядок элементов теперь существуют в одном месте. Раньше новый тип узла приходилось добавлять в две цепочки `if/elif`, которые уже разъехались: в `md2latex` жил мёртвый словарь `cat`, которого на стороне FODT не было вовсе.
Побайтовая сверка: шесть снимков (`example.tex`, `example.fodt`, `example_emdash.fodt`, `pis_custom.tex`, `pis_custom.fodt`, `pis_custom_emdash.fodt`) совпали по SHA-256. Но образцы не дотягиваются до курсива, полужирного, кодовых вставок, ссылок, разрывов строк, цитат, вложенных списков, отсутствующих файлов картинок и экранирования специальных символов LaTeX — поэтому дооптимизационные эмиттеры были дополнительно выкачены из `HEAD` в temp и прогнаны на стресс-документе, покрывающем эти пути. `stress.tex`, `stress.fodt`, `stress_emdash.fodt` тоже идентичны.
`word2md/walker.py`: функция `_handle_paragraph` на 207 строк превращена в тело из 27 строк — собирается неизменяемая запись `_Para` с четырьмя фактами, нужными всем ветвям, затем прогоняется кортеж из одиннадцати обработчиков до первого, вернувшего не `None`. Возврат `None` означает «не мой случай, идём дальше», что сохранило два исходных сквозных пути: подпись со стилем подписи, чей текст не парсится, и строку со стилем библиографии без маркера `[n]`.
Тем же способом проверено и здесь: восемь конвертаций (синтетический DOCX с титульной частью, стилем и полем содержания, подписями продолжений, неразбираемой подписью, кодовыми абзацами, списками через `numPr` и через отступ, разрывами страниц, строкой библиографии без маркера, плюс полный круг `example.md` → DOCX → Markdown, каждая с переключением `keep_toc_pages` и `emit_page_breaks`) дают побайтово идентичный Markdown против дорефакторного обходчика.
Попутно убраны три мёртвых фрагмента: повторный вызов чистой функции при `parsed is None and kind`, no-op `if kind and parsed.kind != kind: pass` (из-за которого весь поиск `caption_kind_from_style` оказывался мёртвым, вместе с импортом), и `try/except` вокруг `re.match` по значению, которое всегда строка.
**Два следствия, требующие внимания.** `mdexport/` остался untracked, при этом уже прописан в `pyproject.toml` и импортируется обоими конвертерами — это пункт P0 в [TODO.md](TODO.md). И при разборе обнаружился реальный баг потери данных в обработчиках списков `word2md`, существовавший и до правок: он сохранён намеренно ради поведенческой нейтральности и описан в [TODO.md](TODO.md) с механизмом и порядком починки.
Спецификации PyInstaller править не пришлось — они идут по статическим импортам.
---
## Как это делалось
Работа шла шестью параллельными исполнителями, разведёнными по владению файлами, чтобы не наступать друг другу на правки. Волна 1: фиксы багов, кэш горячего пути, диаграммы, чистка репозитория. Волна 2: двойной рендер вместе с мёртвым кодом внутри пакета, поскольку они делят `renderer.py`. Отдельным потоком шли сиблинг-конвертеры — единственная область, не пересекавшаяся ни с чем.
Три требования, заданных жёстко всем исполнителям: правки, меняющие раскладку страницы, доказываются побайтовым сравнением вывода, а не чтением кода; вопросы Фазы 1a не трогаются без решения владельца; коммиты и деструктивные git-команды запрещены.
AI-Docs_WriteHuman/docs/cli-gui.md
+84
View File
@@ -0,0 +1,84 @@
# CLI и GUI
Движок один: GUI собирает те же параметры, что и аргументы `python -m md2gost`.
## Основные команды
```bash
python -m md2gost # GUI
python -m md2gost --gui report.md
python -m md2gost report.md -o out.docx --type coursework --check --strict
python -m md2gost report.docx -o report.md # импорт Word → Markdown (word2md)
python -m md2gost report.docx --check-pages # только проверка вёрстки готового DOCX
python -m word2md report.docx -o report.md
```
Справка: `python -m md2gost -h`.
## Соответствие флагов и GUI
| CLI | Где в GUI | Смысл |
|-----|-----------|--------|
| `--type` | Основные → тип | practice, coursework, vkr, PIS_custom, APID_coursework |
| `-o` / `--output` | Выходной DOCX | путь результата |
| `--heading-numbering` | Основные | `manual` (цифры в md) / `auto` (Word) |
| `--toc` | Основные | `native` (поле Word) / `manual` (собирает md2gost) |
| `--emdash-to-hyphen` | Галочка «—» → «-» | по умолчанию выкл. |
| `--hr-pagebreak` | Галочка --- → разрыв | по умолчанию `---` игнорируется |
| `--title` / `--assignment` / `-t` | Настройки → Файлы | титул, задание, шаблон |
| `--auto-title` / `--no-auto-title` | галочка «Автотитул» | автогенерация титула (по умолчанию выкл.) |
| `--student` / `--group` | Настройки → Студент… | ФИО и группа для автотитула |
| `--doc-author-from` / `--doc-author` | Настройки → Метаданные… | автор в свойствах DOCX (`os` / `student` / `custom`) |
| `--doc-title` / `--doc-subject` / `--doc-keywords` / `--doc-comments` / `--doc-category` / `--doc-last-modified-by` | Настройки → Метаданные… | остальные поля File → сведения |
| `--check` / `--check-only` / `--strict` | Галочки проверки ТЗ | замечания по структуре и источникам |
| `--check-pages` | Проверить вёрстку в Word | эвристика полупустых страниц (Word + pywin32) |
| `--table-continuation` | Основные | `word` (по умолчанию), `off`, `legacy`, `caption`, `soft` |
| `--listing-continuation` | Основные | то же для листингов |
| `--table-repeat-header` | Галочка | шапка на фрагментах после word-split |
| `--plantuml-jar` / `--kroki-url` | Настройки → Диаграммы | локальный рендер UML / запасной Kroki |
| `--diagram-fallback` | Диаграммы | `remote` / `local` / `off` (отключает только kroki.io) |
| `--diagram-format` | Диаграммы | `png` / `svg` |
| `--diagram-scale` | Диаграммы | качество PNG PlantUML / локального Mermaid (по умолчанию 2) |
| `--page-start N` | Основные → Смещение страниц | начальный номер PAGE в теле; пусто = сквозной |
| (нет CLI) | Диаграммы → «Скачать Graphviz» | portable Graphviz для DFD (`vendor` или `%LOCALAPPDATA%\md2gost\graphviz`) |
| `--install-chromium` | Диаграммы → «Скачать headless Chromium» | Chromium для Mermaid в `%LOCALAPPDATA%\md2gost` |
| `--schemes` | файл схем / Шаблоны UML | путь к `md2gost.schemes.json` |
| `--styles` | Настройки → Файлы → Стили JSON | оверлей `md2gost.styles.json` (также рядом с `.md`); см. [styles.md](styles.md) |
| `--syntax-highlighting` | (CLI) | подсветка в листингах |
| `--debug` | меню Дебаг | отладочные данные в документе (на одну сборку в GUI) |
## Продолжение таблиц и листингов
DOCX не умеет сам писать «Продолжение Таблицы N» только со 2-й страницы. Режим **`word`** (по умолчанию): после сохранения Word COM режет по реальной пагинации. Нужны Windows + Word + pywin32. Без Word: `--table-continuation off` (и то же для листингов).
## Меню GUI
- **Настройки → Файлы** — шаблон, титул, задание, стили JSON, выходной путь
- **Настройки → Студент…** — ФИО и группа (при первом запуске спрашивают сами)
- **Настройки → Метаданные…** — свойства DOCX (автор, название, тема, теги, примечание)
- **Настройки → Диаграммы** — PlantUML, Graphviz (DFD), Mermaid (Chromium), Kroki, формат, кэш includes
- **Шаблоны UML** — редактор `md2gost.schemes.json`
- **Справка → Инструкция / Документация / Схемы / Промпт для ИИ**
(Документация — встроенный просмотр `docs/*.md`, вшито в exe)
## Автотитульник
Кратко: **по умолчанию выкл.** Вкл. — `--auto-title` или галочка «Автотитул». Рядом с `.md` — `info_conv.yaml`, в MD — опциональный блок `title` (`number` / `year`), ФИО и группа — **Настройки → Студент…** или `--student` / `--group`. Явный `--title` отключает генератор.
Подробно (примеры, таблица полей, приоритеты, FAQ): **[title.md](title.md)**.
## Свойства файла Word
По умолчанию в DOCX пишутся **автор = имя пользователя Windows** и примечание «Создано при помощи md2gost (ТЗ МИРЭА)». Даты создания/изменения ставятся на момент сборки, revision = 1 (чтобы не утекали 2013 год и revision из шаблона).
Задать свои поля: **Настройки → Метаданные…** (сохраняется в `md2gost.user.json`) или флаги `--doc-author-from` / `--doc-author` / `--doc-title` / `--doc-subject` / `--doc-keywords` / `--doc-comments` / `--doc-category` / `--doc-last-modified-by`. Источник автора: `os` (по умолчанию), `student` (ФИО из профиля), `custom` (строка). Пустое `--doc-comments` / пустое примечание в GUI — не писать штамп md2gost.
## Другие форматы
```bash
python -m md2fodt report.md -o report.fodt # LibreOffice
python -m word2md report.docx -o report.md # Word → Markdown (диалект md2gost)
# PDF через LaTeX — см. md2latex/
```
Импорт DOCX подробнее: [word2md.md](word2md.md). В GUI — кнопка «Импорт DOCX→MD» или drop `.docx`.
AI-Docs_WriteHuman/docs/git-cleanup.md
+205
View File
@@ -0,0 +1,205 @@
# Ручная чистка git
Команды для удаления мусора из репозитория. Всё под PowerShell — помни, что `&&` там не работает как разделитель, используй `;` или отдельные вызовы.
Файл описывает то, что осталось сделать руками. То, что уже сделано агентами и лежит в staging, перечислено в конце для сверки.
---
## 0. Подготовка
Чтобы git печатал кириллические имена читаемо, а не как `\320\242...`:
```powershell
git config core.quotepath false
```
Снимок текущего состояния — на случай, если захочется откатиться:
```powershell
git status --short > ..\git-status-before.txt
git stash list
```
Ничего из перечисленного ниже не переписывает историю и не трогает remote, так что откат всегда возможен через `git restore --staged <path>`.
---
## 1. `Other_Code/` — 59 файлов, 1158 КБ
Что это: схемы OOXML (`*.xsd`), скрипты pack/unpack/validate, `document.py`, `utilities.py`, `docx-js.md`, `SKILL.md`. Справочный материал.
Почему можно убирать: ни одного импорта из `md2gost`, `word2md`, `md2latex`, `md2fodt`, `tests/`, ни упоминания в `.spec`, `.bat`, `.github/workflows/`, `pyproject.toml`. Единственные ссылки — раздел 12 в `PROJECT.md` и внутренние перекрёстные ссылки самого каталога.
Проверь сам, прежде чем удалять:
```powershell
git grep -n "Other_Code" -- ':!Other_Code' ':!PROJECT.md'
git grep -nE "^\s*(import|from)\s+(scripts|validation)\b" -- 'md2gost' 'word2md' 'md2latex' 'md2fodt' 'tests'
```
Ожидаемый результат обеих команд — пусто.
### Вариант А: снять с отслеживания, файлы оставить на диске
Подходит, если хочешь держать схемы под рукой локально.
```powershell
git rm -r --cached Other_Code
Add-Content -Path .gitignore -Value "`n# Справочные схемы OOXML (не часть продукта)`n/Other_Code/"
```
### Вариант Б: удалить полностью
```powershell
git rm -r Other_Code
```
### Вариант В: вынести в отдельную ветку и потом удалить
Если материал ценен, но не должен висеть в основной ветке:
```powershell
git subtree split --prefix=Other_Code -b reference/ooxml-schemas
git rm -r Other_Code
```
Ветка `reference/ooxml-schemas` останется локально с полной историей каталога.
После любого варианта подчисти упоминание в `PROJECT.md`, раздел 12.
---
## 2. Личные документы в корне
```
Практическая_работа_6.docx 42 КБ
ТарасовИА_КР_v3.docx 2326 КБ
```
Та же категория, что и `md2gost.user.json`: персональные данные, причём ФИО прямо в имени файла. Ни одной ссылки из кода, тестов или сборочных скриптов.
Снять с отслеживания, файлы оставить на диске:
```powershell
git rm --cached "Практическая_работа_6.docx"
git rm --cached "ТарасовИА_КР_v3.docx"
```
Если кириллица в аргументах ломается, обойди её через pathspec по расширению и отбери нужное вручную:
```powershell
git ls-files "*.docx"
```
Правило в `.gitignore`, чтобы не вернулись:
```powershell
Add-Content -Path .gitignore -Value "`n# Личные документы (ФИО в имени файла)`n/*.docx`n!md2gost/Template.docx`n!md2gost/TitleTemplate.docx"
```
**Осторожно с этим правилом.** `md2gost/Template.docx` и `md2gost/TitleTemplate.docx` — живые файлы, они force-include в колесо через `pyproject.toml` и попадают в exe через `.spec`. Правило выше их исключает, но проверь результат:
```powershell
git check-ignore -v md2gost/Template.docx md2gost/TitleTemplate.docx
```
Обе строки должны вернуть пусто (то есть файлы НЕ игнорируются). Если вернули правило — убери `/*.docx` и перечисли два личных файла поимённо.
---
## 3. Проверка результата
```powershell
git status --short
git ls-files | Measure-Object | Select-Object -ExpandProperty Count
```
Размер отслеживаемого дерева до и после:
```powershell
(git ls-files | ForEach-Object { (Get-Item -LiteralPath $_).Length } | Measure-Object -Sum).Sum/1MB
```
Убедись, что ничего живого не выпало:
```powershell
.venv\Scripts\python.exe -c "import md2gost, word2md, md2latex, md2fodt; print('ok')"
$env:PYTHONIOENCODING="utf-8"; .venv\Scripts\python.exe -m md2gost --help
.venv\Scripts\python.exe -m pytest -q
```
Переменная `PYTHONIOENCODING` нужна из-за cp1251 в консоли — без неё `--help` падает на символе `→`, хотя код в порядке.
---
## 4. Про историю: снятие с отслеживания её не чистит
Это важно понимать. `git rm --cached` убирает файл из индекса и будущих коммитов, но все прошлые коммиты остаются нетронутыми. То есть:
- `md2gost.user.json` с твоими ФИО и группой **по-прежнему лежит в истории**
- `ТарасовИА_КР_v3.docx` тоже, все 2.3 МБ, в каждом коммите, где он менялся
- удалённые прототипы `mm2.py`/`mm3.py` и `Other_Code/` продолжают занимать место в `.git`
Если репозиторий приватный и таким останется — этого достаточно, дальше можно не читать.
Если планируешь публиковать, историю надо переписывать. Инструмент — `git filter-repo` (BFG устарел):
```powershell
uvx git-filter-repo --path md2gost.user.json --invert-paths
uvx git-filter-repo --path "ТарасовИА_КР_v3.docx" --invert-paths
uvx git-filter-repo --path Other_Code --invert-paths
```
Перед этим обязательно:
1. Сделай полную копию каталога `.git`, а лучше всего репозитория — операция необратима.
2. Учти, что все хеши коммитов сменятся. Если репозиторий уже где-то запушен, всем придётся клонировать заново.
3. Прогони `git reflog expire --expire=now --all; git gc --prune=now --aggressive`, иначе объекты останутся в паке.
Я специально не делал это автоматически: перезапись истории — необратимая операция, её стоит запускать осознанно и на копии.
---
## Приложение: что уже сделано агентами
Всё перечисленное лежит в staging, **не закоммичено**. Просмотри `git diff --cached` перед коммитом.
Удалено с диска (мёртвые прототипы, 6777 строк):
```
mm2.py mm3.py mm4.py mm5.py main12.py main.py
asd.py parser.py font.py _audit_tmp.py
poetry.lock requirements.txt
```
Снято с отслеживания, файлы остались на диске:
```
ReadMe.docx md2gost/README.docx
tmp_listing_word.md/.docx tmp_readme_word.docx
tmp_readme_word2.docx README.md1
examples/example_out.docx examples/toc_manual.docx
examples/toc_native.docx tests/_idef0_preview*.png/.svg
latex/mirea/Settings/FiraCode-Regular.otf
ad/ (4 файла) md2gost.user.json
```
Перенесено с сохранением истории:
```
_method_extract.txt -> docs/reference/method-mirea-2022.txt
tests/extended_mardown/ -> tests/extended_markdown/
```
Добавлено: `md2gost.user.json.example` с пустыми полями.
### Побочный эффект правил игнора, о котором стоит знать
Новые правила `/tmp_*.png` и `/tmp_*.puml` захватили рабочие черновики `tmp_org_full.*`, `tmp_org_uml.*`, `tmp_arch.*` — они пропали из `git status`, хотя на диске целы. Если какой-то из них нужен под версионным контролем, добавь исключение:
```powershell
Add-Content -Path .gitignore -Value "!/tmp_arch.puml"
```
Каталог `ai/` не тронут и остаётся untracked.
AI-Docs_WriteHuman/docs/markdown.md
+159
View File
@@ -0,0 +1,159 @@
# Синтаксис Markdown (диалект md2gost)
Обычный Markdown описывает структуру текста. Для отчёта по ГОСТ нужны ещё: спецразделы без номера, подписи объектов, перекрёстные ссылки, библиография в заданном виде. **md2gost** расширяет MD ровно этими элементами; конвертер сам нумерует рисунки/таблицы/листинги и оформляет DOCX.
## Что совпадает с обычным MD
- Заголовки `#` … `######`
- Абзацы, **жирный**, *курсив*
- Маркированные и нумерованные списки
- Таблицы `| … |`
- Картинки `![alt](path.png)`
- Блоки кода в ограде ` ```язык `
- Формулы `$$ … $$` (и инлайн `$…$` где поддерживается)
## Зачем расширения
| Задача | Обычный MD | md2gost |
|--------|------------|---------|
| Введение без номера «1» | `# Введение` → станет разделом 1 | `# *ВВЕДЕНИЕ` |
| Подпись «Рисунок 1.1 — …» | руками / HTML | `%id` или title у картинки |
| «см. рис. 2» в тексте | нет семантики | `@Рисунок:id` |
| UML → картинка в Word | экспорт PNG вручную | fence `` ```uml `` / схема → Рисунок |
## Спецразделы
Звёздочка `*` = без автоматической нумерации раздела. Текст — ПРОПИСНЫМИ:
```markdown
# *СОДЕРЖАНИЕ
[TOC]
# *ВВЕДЕНИЕ
# 1 Название первого раздела
## 1.1 Подраздел
# *ЗАКЛЮЧЕНИЕ
# *СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ
# *ПРИЛОЖЕНИЯ
```
- После `# *СОДЕРЖАНИЕ` обязателен `[TOC]`.
- В конце названия заголовка точку не ставить.
- Для `PIS_custom` структура другая (практические работы) — см. [types.md](types.md).
## Рисунок (файл)
```markdown
Текст со ссылкой на @Рисунок:arch.
![описание](images/arch.png "%arch Название рисунка")
```
В тексте пишите **«Рисунок»**, не «рис.» / «рис».
## Таблица
```markdown
См. @Таблица:cmp.
%cmp Название таблицы
| A | B |
|---|---|
| 1 | 2 |
```
Склеивание ячеек:
- `^` — rowspan (продолжение ячейки сверху)
- `>` — colspan (продолжение слева)
Не ставить `^`/`>` в заголовочной строке; `>` — не в первом столбце. Графу «№ п/п» не добавлять.
## Листинг
~~~markdown
Фрагмент в @Листинг:code1.
%code1 Название листинга
```python
def f():
return 1
```
~~~
## Диаграмма → Рисунок
Перед блоком — `%id Подпись`. Языки: `uml`, `plantuml`, `mermaid`/`mmd`, `idef0`, `dfd`/`data-flow-diagram` (Graphviz вшитый/PATH или Kroki), или id схемы (`c4`, `usecase`, …).
- `+listing` — ещё и Листинг с исходником
- `+landscape` — альбомная страница под широкий рисунок/таблицу
Подробности: [schemes.md](schemes.md).
## Формула
```markdown
%eq1
$$
E = mc^2
$$
Зависимость (@Формула:eq1) используется далее.
```
Нумеруются **только** формулы, на которые есть `@Формула:…`.
## Ссылки на объекты
`@Рисунок:id`, `@Таблица:id`, `@Листинг:id`, `@Формула:id` — id совпадает с меткой после `%` или в title картинки.
## Источники
В тексте: `[1]`, `[2, 3]` (для ВКР — `[1.5]`). В DOCX номера становятся ссылками на пункты списка источников.
В списке:
```markdown
[1]: Иванов И. И. Название. — М.: Наука, 2024. — 120 с.
```
Во **ВВЕДЕНИИ** и **ЗАКЛЮЧЕНИИ** ссылок `[n]` быть не должно.
## Приложения
```markdown
# *ПРИЛОЖЕНИЯ
## Приложение А Листинг модуля
…
## Приложение Б Графический материал
```
Буквы: А, Б, В, Г, Д, Е, Ж, И, К… **Нельзя:** Ё, З, Й, О, Ч, Ь, Ы, Ъ.
## Тире и разрыв страницы
- Тире в предложениях: «—» (по умолчанию сохраняется). Замена на «-»: `--emdash-to-hyphen`.
- Строка `---` / `***` / `___` по умолчанию **игнорируется**. Разрыв страницы: `--hr-pagebreak` или галочка в GUI.
## Автотитульник (метаданные в MD)
В начале файла можно указать блок с оградой `title` (номер работы, год, оверрайды полей). Рядом с файлом — `info_conv.yaml` с институтом, кафедрой, дисциплиной и преподавателем. ФИО и группа студента задаются в GUI / CLI, не в yaml. Автогенерация титула **по умолчанию выкл.** — включите `--auto-title` или галочку «Автотитул».
Подробно: [title.md](title.md).
## Запрещено в отчёте
- «рис.», «табл.»
- графа «№ п/п»
- сноски `[^1]`
- формулы обычным текстом вместо `$$…$$`
- нумерация спецразделов (`# ВВЕДЕНИЕ` вместо `# *ВВЕДЕНИЕ`)
AI-Docs_WriteHuman/docs/prompts.md
+34
View File
@@ -0,0 +1,34 @@
# Промпты для ИИ
Промпты лежат в [`prompts/`](../prompts/). В GUI: **Справка → Промпт для ИИ** — выбрать, при необходимости **дописать схемы**, скопировать в буфер. Полная документация также доступна в **Справка → Документация** (вшита в exe).
## Какие файлы
| Файл | Когда |
|------|--------|
| [`generate-md.md`](../prompts/generate-md.md) | Базовый: диалект md2gost, чем отличается от обычного MD; UML/Mermaid рисует конвертер |
| [`generate-mirea-report.md`](../prompts/generate-mirea-report.md) | Полный отчёт ГОСТ / МИРЭА (`coursework`, `practice`, `vkr`) |
| [`generate-pis-custom-report.md`](../prompts/generate-pis-custom-report.md) | Итоговый отчёт ПИС (`PIS_custom`) |
| [`emulate-student.md`](../prompts/emulate-student.md) | После любого generate-*: текст про предмет, не отчёт модели о сдаче ТЗ |
## Как пользоваться
1. Откройте промпт (файл или GUI). При необходимости добавьте `emulate-student` после базового generate-*.
2. В GUI включите нужные схемы (C4, usecase, …) — в конец промпта добавятся макросы и `ai-prompt` из `md2gost.schemes.json`.
3. Скопируйте собранный текст в ChatGPT / Claude / Cursor / Copilot.
4. Следующим сообщением: тип работы, тема, черновик / требования.
5. Сохраните ответ как `.md` и конвертируйте:
```bash
python -m md2gost report.md -o report.docx --type coursework --check --strict
```
## Зачем кнопки схем
Базовый промпт уже говорит: блоки `` ```uml `` / `` ```mermaid `` / `` ```uml-c4 `` конвертер сам превратит в Рисунок. Кнопки нужны, когда модели надо знать **конкретные макросы** выбранной схемы (Person/Rel для C4, actor/usecase и т.д.) — в том числе пользовательских из «Шаблоны UML».
## Подробнее о синтаксисе
- [markdown.md](markdown.md)
- [schemes.md](schemes.md)
- [prompts/README.md](../prompts/README.md)
AI-Docs_WriteHuman/docs/quickstart.md
+64
View File
@@ -0,0 +1,64 @@
# Быстрый старт
## Установка
Нужен Python 3.10+.
```bash
uv sync # окружение по uv.lock (канонический lock-файл)
# или
pip install -e .
```
Для продолжения таблиц/листингов через Word COM (режим `word` по умолчанию) на Windows:
```bash
pip install pywin32
```
Нужны установленный Microsoft Word.
## Запуск
```bash
python -m md2gost # GUI без файла
python -m md2gost --gui
python -m md2gost report.md -o report.docx --type coursework --check
md2gost-gui # то же GUI (entry point)
```
### Windows exe
В корне репозитория: `build-exe.bat` → `dist\md2gost.exe`.
- Двойной клик — GUI.
- CLI: `md2gost.exe report.md -o report.docx --type coursework`.
## GUI за минуту
1. Перетащите `.md` в верхнюю область (или кликните по ней).
2. Выберите тип документа (`practice` по умолчанию).
3. При необходимости: Настройки → Файлы (титул, задание), **Настройки → Студент…** (ФИО и группа для автотитула), **Настройки → Метаданные…** (свойства DOCX), Настройки → Диаграммы, меню «Шаблоны UML».
4. Нажмите «Конвертировать».
Справка в меню: **Инструкция**, **Схемы**, **Промпт для ИИ**.
Автотитул (`info_conv.yaml` + блок `title`): [title.md](title.md).
## Типы документов (кратко)
| `--type` | Назначение |
|----------|------------|
| `practice` / `coursework` | Практика / курсовая по ТЗ МИРЭА |
| `vkr` | ВКР (раздельный список, графическое приложение) |
| `PIS_custom` | Итоговый отчёт по практическим работам |
| `APID_coursework` | Курсовая «Архитектура приложений и данных» |
Подробнее: [types.md](types.md).
## Следующие шаги
- Написать отчёт в диалекте md2gost: [markdown.md](markdown.md)
- Автотитульник: [title.md](title.md)
- Вставить диаграммы: [schemes.md](schemes.md)
- Сгенерировать `.md` через ИИ: [prompts.md](prompts.md)
AI-Docs_WriteHuman/docs/reference/method-mirea-2022.txt
+988
View File
@@ -0,0 +1,988 @@
УДК 378
ББК 65
К 43
Кириллина Ю.В. Требования к оформлению отчетов по практикам, курсовых работ и
ВКР бакалавров и магистров [Электронный ресурс]: Методические указания / Кириллина
Ю.В., Лагунова А.Д., Бергер Е.Г. — М.: МИРЭА – Российский технологический
университет, 2022. — 1 электрон. опт. диск (CD-ROM)
Методические указания знакомят студентов с требованиями по оформлению учебных
работ, таких как курсовые работы, отчеты по практикам, выпускная квалификационная
работа. Использование методических указаний позволит студентам грамотно оформлять
учебные работы, которые они выполняют согласно учебному плану в процессе обучения.
Данные методические указания основаны на ГОСТ 7.32 – 2017 Система стандартов по
информации, б иблиотечному и издательскому делу. Отчет о научно -исследовательской
работе. Структура и правила и оформления.
Предназначено для студентов по направлени ям подготовки 09.03.03 Прикладная
информатика, 09.0 4.03 Прикладная информатика , а также может быть использовано
студентами других направлений подготовки для получения навыков грамотного оформления
учебных работ.
Методические указания издаются в авторской редакции.
Авторский коллектив: Кириллина Юлия Владимировна, Лагунова Анна Дмитриевна, Бергер
Екатерина Геннадьевна
Рецензенты:
Одинцова Мария Александровна , к.т.н., доцент, доцент кафедры «Предметно -
ориентированные информационные системы» Института кибербезопасности и
цифровых технологий РТУ МИРЭА
Системные требования:
Наличие операционной системы Windows, поддерживаемой производителем.
Наличие свободного места в оперативной памяти не менее 128 Мб.
Наличие свободного места в памяти постоянного хранения (на жестком диске) не менее 30 Мб.
Наличие интерфейса ввода информации.
Дополнительные программные средства: программа для чтения pdf-файлов (Adobe Reader).
Подписано к использованию по решению Редакционно-издательского совета
МИРЭА — Российский технологический университет.
Обьем: 5.39 мб
Тираж: 10
© Кириллина Ю.В., Лагунова А.Д.,
Бергер Е.Г., 2022
© МИРЭА – Российский
технологический университет, 2022
3
СОДЕРЖАНИЕ
ПРЕДИСЛОВИЕ ...................................................................................................... 4
1. СТРУКТУРА УЧЕБНОЙ РАБОТЫ .................................................................... 5
2. ОФОРМЛЕНИЕ ТЕКСТА ДОКУМЕНТА ........................................................ 12
3. ОФОРМЛЕНИЕ ИЛЛЮСТРАЦИЙ И ТАБЛИЦ В УЧЕБНОЙ РАБОТЕ ....... 17
4. ОФОРМЛЕНИЕ ТЕКСТА (ЛИСТИНГА) ПРОГРАММЫ В УЧЕБНОЙ
РАБОТЕ .................................................................................................................. 27
5. ОФОРМЛЕНИЕ СПИСКА ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ В
УЧЕБНОЙ РАБОТЕ ............................................................................................... 30
6. ОФОРМЛЕНИЕ ПРИЛОЖЕНИЙ В УЧЕБНОЙ РАБОТЕ .............................. 34
СПИСОК ИСТОЧНИКОВ И ЛИТЕРАТУРЫ ...................................................... 37
ПРИЛОЖЕНИЕ А .................................................................................................. 38
ПРИЛОЖЕНИЕ Б................................................................................................... 39
ПРИЛОЖЕНИЕ В .................................................................................................. 41
ПРИЛОЖЕНИЕ Г................................................................................................... 42
ПРИЛОЖЕНИЕ Д .................................................................................................. 44
ПРИЛОЖЕНИЕ Е .................................................................................................. 45
4
ПРЕДИСЛОВИЕ
В процессе обучения студентам направлений подготовки 09.03.03, 09.04.03
Прикладная информатика необходимо писать и оформлять курсовые работы, от-
четы по различным видам и типам практик, а также выпускную квалификацион-
ную работу (далее по тексту — учебные работы). Данные методические указания
предназначены для студентов вышеуказанных направлений подготовки.
Целью данных методических указаний является поддержка грамотного
оформления текстовых документов студентами.
Задачами методических указаний являются:
• ознакомление студентов с общей структурой учебных работ, таких как
курсовая работа, отчет по практике, выпускная квалификационная ра-
бота (ВКР);
• ознакомление студентов с правилами оформления учебных работ.
Основой для создания методических указаний является ГОСТ 7.32 — 2017
Система стандартов по информации, библиотечному и издательскому делу.
Отчет о научно-исследовательской работе. Структура и правила и оформления.
Методические указания составлены в соответствии с:
• СМКО МИРЭА 7.5.1/03.П.67- 18 Положение о выпускной квалифика-
ционной работе студентов, обучающихся по образовательным про-
граммам подготовки бакалавров;
• СМКО МИРЭА 7.5.1/03.П.68- 18 Положение о выпускной квалифика-
ционной работе студентов, обучающихся по образовательным про-
граммам подготовки магистров;
• СМКО МИРЭА 7.5.1/04.И.05- 18 Инструкция по организации и прове-
дению курсового проектирования.
5
1. СТРУКТУРА УЧЕБНОЙ РАБОТЫ
Учебная работа студента должна иметь определенную структуру.
Структура конкретной учебной работы регламентируется методическими
указаниями по написанию курсовой работы, методическими указаниями по
написанию отчета по практике, методическими указаниями по написанию ВКР,
которые разрабатываются преподавателями выпускающей кафедры и издаются
редакционно-издательским отделом университета. В се изданные методически е
указания выпускающей кафедры студент может найти на сайте университет а в
разделе Студентам, далее Библиотека.
В тоже время общая структура учебной работы включает в себя:
• ый лист;
• ие;
• ие;
• ие;
• ием;
• ие;
• иков;
• ия.
Титульный лист учебной работы имеет утвержденную форму , выдается
преподавателем, который руководит курсовой работой/практикой/ВКР.
На титульном листе в обязательном порядке проставляется подпись
руководителя учебной работы и студента. В случае, если в кач естве учебной
работы выступает курсовая работа, то на не м необходима подпись второго
преподавателя, участвующего в процедуре защиты курсовой работы. В слу чае,
если в качестве учебной работы выступает ВКР, то на титульном листе
необходима подпись заведующего выпускающей кафедрой. Примеры титульных
листов различных учебных работ приведены в Приложении А .
му и выдается
преподавателем, который руководит курсовой работой/практикой/ВКР.
аботы) — т, в
яется абота). ие подписывается
аботы. совых
абот, а т а к ж е о т ч е т о в п о п р а к т и к е ие обязательно ждается
ой. абот
дополнительно согласуется с директор ом института. Факт принятия
студентом задания к работе подтверждается подписью студента на задании.
6
Кроме подписей в задании должны быть указаны дата утверждения задания
заведующим кафедрой, дата выдачи задания, дата принятия задания к
исполнению. Примеры заданий различных учебных работ приведены в
Приложении Б.
афической
частей в учебной работе устанавливаются методическими указаниями по
написанию курсовой работы, методическими указаниями по написанию отчета
по практике, методическими указаниями по написанию ВКР .
авливается методическими
указаниями по написанию курсовой работы, методическими указаниями по
написанию отчета по практике, методическими указаниями по написанию ВКР ,
а также положениями, приведенными в предисловии данного пособия.
Текст основной части учебной работы еобходимости а азделы,
азделы, пункты . кты имеют заголовки, четко и
ктов.
а листе, который расположен ого листа и
ия, азделов,
иц. иц
а быть
ая.
ия заголовков:
• аздела — я;
• аздела — я;
• ктов — ей.
та,
ые с абзацевого отступа.
аков
ия пишется заголовок.
а б ы т ь в
ﮦ ﮦ аздела,
ых точками.
Параметры оформления заголовков в учебной работе представлены в табл.
2.1. Важно обратить внимание на то, что интервалы между заголовками
выставляются в единицах измерения — мм, а не пт.
На рис. 2.1 представлен пример внешнего вида заголовков выпускной
квалификационной работы и курсовой работы с учетом установленных
параметров страниц для учебной работы.
7
Таблица 2.1. Параметры оформления заголовков в учебной работе
Параметр Заголовок
первого урﮦовнﮦя
Заголовок
второго уровня
Заголовок
третьего уровня
ифт
Шрﮦифт Times New Roman
Нﮦачерﮦтанﮦие полужирﮦнﮦый
Подчерﮦкиванﮦие нﮦет
Видоизменﮦенﮦие все прﮦописнﮦые нﮦет нﮦет
Рﮦазмерﮦ 18 пт 16 пт 14 пт
Цвет текста Авто (черﮦнﮦый)
Абзац
Вырﮦавнﮦиванﮦие По левому крﮦаю
Перﮦвая стрﮦока нﮦет
Отступ слева 1,25 см
Отступ спрﮦава 0 мм
Инﮦтерﮦвал перﮦед 0 мм 15 мм 15 мм
Инﮦтерﮦвал после 10 мм 10 мм 10 мм
Междустрﮦочнﮦый
инﮦтерﮦвал
Полуторﮦнﮦый
Положенﮦие нﮦа
ице
Не отрывать от
следующего
С новой страницы
Не отрывать от
следующего
Запрет висящих строк
Нﮦе отрывать от
следующего
Запрет висящих строк
Рисунок 2.1. Пример внешнего вида заголовков
8
азделы «СОДЕРЖАНИЕ», «ВВЕДЕНИЕ», «ЗАКЛЮЧЕНИЕ», «СПИСОК
ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ », «П РИЛОЖЕНИЕ»/«ПРИЛОЖЕНИЯ»
уются.
Разделы «СОДЕРЖАНИЕ» и «СПИСОК ИСПОЛЬЗОВАННЫХ
ИСТОЧНИКОВ» выравниваются по центру страницы.
ие
азделяют точкой.
е Word используется
вкладка «Стили» (рис. 2.2). ﮦ ов
о
ить азу
ия.
Рисунок 2.2. Использование вкладки «Стили» в текстовом редакторе Word
ить
а «Стили» ять
овые стили (рис. 2.3).
ые соответствующими стилями, позволяют
ие.
ктов должны
ии, и
соответственно наоборот. Для обеспечения этого содержание учебной работы
должно формироваться с помощью встроенной функции Оглавление.
ИЕ»,
ием по
у. Важно обратить внимание на значения интервала перед самим
заголовком и после него для того, чтобы обеспечить нужные интервалы между
заголовков и последующими пунктами самого содержания учебной работы.
ю
«Ссылки» → а ю и с
ителя строки «. . . . . . . .» ( рис. 2.4).
9
ить и
овать.
Рисунок 2.3. Редактирование заголовков в текстовом редакторе Word с
использование диалогового окна «Стили»
Рисунок 2.4. Формирование содержания через Автособираемое оглавление
иц,
ом
овить поле».
10
При создании содержания слово ОГЛАВЛЕНИЕ заменяется в ручном
режиме на СОДЕРЖАНИЕ с выставлением необходимых параметров,
характерных для заголовков первого уровня.
ой
текст» без отступа первой строки аю.
я,
ии
ыми буквами (рис. 2.5), аналогично тому, как они
оформлены в учебной работе за исключением того, что полужирное начертание
не применяется.
Рисунок 2.5. Пример оформления содержания в ВКР
11
ии текст попадает иц
кте отсутствует отточие ицы, то часть
очку.
12
2. ОФОРМЛЕНИЕ ТЕКСТА ДОКУМЕНТА
ты учебной работы ой
е листа.
В случае представления учебной работы в бумажном виде она а быть
мата А4.
Учебная работа ых
ﮦ илами.
Учебная работа проверяется руководителем на соблюдение правил
оформления, в случае несоответствия работы она не допускается до защиты и
выставления оценки, и направляется на доработку.
Текст документа должен быть кратким, четким и не допускать различных
толкований. В докуме нтах должны применяться научно-технические те рмины,
обозначения и определен ия общеп ринятые в научно-технической лите ратуре
Стиль изложения текста в учебной работе строго нау чный, подстиль —
собственно-научный. е допускается:
• ицизмы,
ализмы;
• ия;
• усской
тами и
ая
овка;
• и
ﮦ .
Текст учебной работы печатается, соблюдая следующие размеры полей:
левое — 30 мм, правое — 10 мм, верхнее и нижнее — 20 мм. Абзацный отступ
должен быть одинаковым по всему тексту и равен 1,25 см [1].
а листах в рамках еще
незаконченного раздела (см. Приложение В).
иц.
Не допускается размещать заголовки в кон це страницы, а основной текст
переносить на следующую страницу.
Текст ифтом
ого цвета , размер шрифта — 14 пт, тип шрифта для основного текста
учебной работы — Times NewтRoman.
ой текст» (табл. 2.1).
13
ифт»,
а знаков абзаца и других скрытых знаков
форматирования ца абзаца и
аки» (ая» →
ифт» → ¶).
Таблица 2.1. Параметры оформления основного текста учебной работы
Параметр Значение
ифт
Шрﮦифт Times New Roman
Нﮦачерﮦтанﮦие Обычнﮦый
Подчерﮦкиванﮦие нﮦет
Видоизменﮦенﮦие нﮦет
Рﮦазмерﮦ 14 пт
Цвет текста Авто (черный)
Абзац
Выравнивание По ширине
Первая строка 1,25 см.
Отступ слева нет
Отступ справа нﮦет
Интервал перﮦед нﮦет
Интервал после нет
Междустрочный интервал Полуторный
Положение на странице Запрет висящих строк
Пробел ставится после любого знака пунктуации, но не перед ним. При этом
не ставятся п робелы после отк рывающих скобок и кавычек, так же как и пе ред
закрывающими скобками и кавычками.
Кавычки в русском тексте (включая список использова нных источ ников)
имеют форму «…», а в английском — "…".
ая.
ицы учебной работы оставляемыми по
ифт — ﮦ12 пт).
ﮦ ицы
е ставится:
• титульный лист;
• ие;
• ие.
е
аки, такие как
«+», «–», «=», «>», «<» и так далее. В тексте их следует писать словами: «плюс»,
ьше».
аки:
14
1. ак дефиса «-» обелами и используется:
• жащих дефисы (во-первых,
физико-математический, кто-либо);
• валов (100-150 Мб).
2. уса «–» ия.
3. е «—обелами и используется в соответствии с
ктуации (Классификаторﮦ —это
систематизированный …).
абские
талов, полугодий,
ами.
ами, ы
иями (… в начале XXI века).
ых
ий (… во 2 разделе, … характерно для середины 1980 годов).
ﮦ ой и той же
его числа
(…составляет 200, 250, 300 руб.)ица
ﮦ е (… длиной 20-25 см).
ﮦ иц
ﮦ ами, а числа без
ﮦ ицы до девяти
— словами (провести испытан ия семи т руб, каждая дли ной 5 м) . ые
обей с ипользованием
запятой при написании (20,5 см).
ый и ый спис ки уются стилем
ой текст».
Таблица 2.2. Параметры оформления списков
Параметр Значение
Марﮦкирﮦованﮦнﮦый список –, ―, ●, ■, ○
Нﮦумерﮦованﮦнﮦый список 1.
а)
Положенﮦие марﮦкерﮦа (нﮦомерﮦа) Отступ 1,25 см
Положенﮦие текста Табуляция после 2,25 см
Отступ 2,25 см
ﮦ а во всем
ькой
15
чивается — кт в
чивается точкой).
ﮦ ой буквы и
чиваться точкой (рис. 2.1-2.3).
Рисунок 2.1. Пример 1 оформления списка в учебной работе
Рисунок 2.2. Пример 2 оформления списка в учебной работе
16
Рисунок 2.3. Пример 3 оформления списка в учебной работе
В случае необходимости применения для нумерованного списка строчных
букв русского алфавита, список начинают с буквы «а» (за исключением букв ё,
з, й, о, ч, ъ, ы, ь) [1].
Внутри списка не могут располагаться иллюстрации и таблицы.
При выполнении учебной работы необходимо соблюдать равномерную
плотность и четкость изображения по все й работе. Все линии, буквы, цифры и
знаки должны иметь одинаковую контрастность по всему тексту.
17
3. ОФОРМЛЕНИЕ ИЛЛЮСТРАЦИЙ И ТАБЛИЦ В
УЧЕБНОЙ РАБОТЕ
Количество иллюстраций в учебной работе должно быть достаточ ным для
пояснения излагаемого текста, в некоторых случаях обязательные иллюстрации
регламентируются методическими указаниями по написанию курсовой работы,
методическими указаниями по написанию отчета по практике, методическими
указаниями по написанию ВКР.
о после
ице (по
возможности ближе к соответствующим частям текста учебной работы) с
у без абзацного отступа и первой строки.
ами.
аздела —
ﮦ ﮦ азделяются точкой.
ации
ации (табл. 3.1).
Таблица 3.1. Параметры оформления подписи иллюстраций
Параметр Значение
ифт
Шрифт Times New Roman
Начертание Полужирﮦнﮦый
Подчеркивание нет
Видоизменﮦение нет
Размер 12 пт
Цвет текста Авто (черﮦнﮦый)
Абзац
Выравнивание По центру
Первая строка 0 см
Отступ слева 0 см
Отступ спрﮦава нет
Интервал перﮦед 0 мм
Интервал после 6 мм
Междустрочный интервал Одинарный
Положение на странице Запрет висящих строк
ия
е ставится . Предложение, в котором автор ссылается на
рисунок, должно заканчиваться точкой, а не двоеточие м, т а к к а к э т о является
нарушением правил пунктуации. (рис. 3.1).
ием
а.
18
Рисунок 3.1. Пример оформления рисунка с учетом установленных параметров
страниц учебной работы
углых скобках или
ﮦ :
• план проекта иллюстрирует диаграмма Ганта (Рисунок 1.1);
• дерево функций представлено на Рисунке 1.1.
о
ия по часовой
а 90 яется с
ую с помощью команды главного меню «Макет» . При
размещении рисунка на отдельной странице с альбомной ориентацией
необходимо установить в Параметрах страницы вертикальное выравнивание
по центру.
Страницы с альбомной ориентацией предназначены только для
рисунков и таблиц, нельзя размещать на них основной текст (Приложение Г,
рис. Г.1-Г.2).
19
Сначала устанавливаются разрывы страницы, начиная со следующей
страницы, а потом меняется ориентация с книжной на альбомную (рис. 3.2-3.3).
Рисунок 3.2. Переход от книжной ориентации к альбомной
Рисунок 3.3. Пример оформления рисунка на странице с альбомной ориентацией
20
В случае, если рисунок завершает раздел, подраздел или пункт
рекомендуется после него сформулиро вать заключительное предложение. Для
раздела это будет заключительное предложение, подводящее итоги по
выполненной работе в соответствующем разделе. Для подраздела или пункта это
будет завершающее предложение, обеспечивающее переход к следующему
подразделу или пункту (рис. 3.4-3.5).
Рисунок 3.4. Пример завершения раздела и переход к следующему
Все иллюстрации должны иметь границы четко по представляемому
рисунку, схеме и т.д., и не допускается пустая, неинформативная часть в
иллюстрации, занимающая место, предназначеннное для основного текста.
На рис. 3.6 представлена правильная и неправильная обрезка границ
иллюстрации.
Вне зависимости от того, каков формат представления учебной работы:
распечатанная бумажная версия или электронный файл, все иллюстрации
должны удовлетворять требованию их четкого воспроизведения, то есть должна
быть обеспечена читабельность иллюстраций без необходимости прибегать к
увеличению масштаба представленного материала.
21
Рисунок 3.5. Пример завершения подраздела и переход к следующему подразделу в
курсовой работе
Рисунок 3.6. Пример правильной обрезки границ иллюстрации (левая часть) и
неправильной обрезки границ илллюстрации (правая часть)
22
Кроме того, рисунки, представляющие собой чертежи, графики, диаграммы,
схемы, помещаемые в учебной работе , должны соответствовать требованиям
стандартов Единой системы конструкторской документации (ЕСКД) .
ия
показателей.
ие таблицы атким.
ад таблицей.
ие таблицы пишется без абзацного отступа и первой строки у
це
е ставится.
ами аздела —
ﮦ ﮦ азделяются точкой.
ом
еобходимости,
ту.
ﮦ ие ячеек
е допускается.
ед
е Word).
Параметры оформления таблицы в учебной работе представлены в табл. 3.2.
Таблица 3.2. Параметры оформления таблицы
Параметр Надпись таблицы Текст таблицы
ифт
Шрифт Times New Roman
ие Курсив Обычный, полужирный,
курсив
Подчеркиванﮦие нет
Видоизменение нет
Размер 12 пт
Цвет текста Авто (черный)
Абзац
Выравнивание По левому краю По центру, по левому
краю
Первая стрﮦока 0 см
Отступ слева 0 см
Отступ справа нет
Интервал перед 6 мм 0 мм
Интервал после 0 мм
Междустрочный интервал Одинﮦарный
Положение нﮦа странице Запрет висящих строк
23
а все таблицы учебной работы ы ссылки в тексте.
углых скобках или включаются в
ие. Если ссылка на таблицу завершает предложение, то в конце
предложения ставится точка.
ием
углых скобках
ﮦ :
• далее представлен планﮦпроекта (Таблица 3.1);
• планﮦпроекта представлен в Таблице 3.1 (рис. 3.7).
Рисунок 3.7. Пример представления таблицы
ие
ую
угими частями пишется
адпись таблицы»
(рис. 3.8).
Не допускаются таблицы в одну строчку, а также не допускается оставлять
на странице только заголовок к таблице или заголовок с заголовками граф
(Приложение Г, рис. Г.3).
ации
ед их
ием.
Все таблицы в учебной работе должны быть оформлены единообразно с
точки зрения применяемого стиля для оформления заголовков и подзаголовков
граф, а также строк таблицы.
24
Рисунок 3.8. Пример оформления переноса таблицы в учебной работе
ия,
ия
е
о под
мулой.
ием
мул Microsoft Equation или MathType.
а вкладке «Вставка» →«Уравнение» (рис.
3.9).
Рисунок 3.9. Возможности контекстного меню «Уравнение»
25
Не допускается формулы оформлять как основной текст, основным
шрифтом.
мулы, ивается по
у. а
ока.
а ака
ус ( –ия (×) или
ия яется.
ию.
тов следует
ости, в какой
муле.
ают без абзацного отступа со слова «где»
его.
Значение каждого символа и числового коэффицие нта следует давать с
новой строки, располагая символы один под другим (рис. 3.10).
Рисунок 3.10. Пример оформления последовательности формул в учебной работе
26
Если формула является концом предложения, то ставится точка, если после
формулы предложение продолжается — запятая.
Формулы нумеруются последовательно в пределах раздела арабскими
цифрами в круглых скобках, выровненных по правому краю. Нумеруются только
те формулы, на которые имеются ссылки в тексте.
Ссылки в тексте на номер формулы даются в круглых скобках.
Вне зависимости от способа выполнения учебной работы качество
напечатанного текста и оформления иллюстраций, таблиц, распечаток программ
должно удовлетворять требованию их четкого воспроизведения.
27
4. ОФОРМЛЕНИЕ ТЕКСТА (ЛИСТИНГА) ПРОГРАММЫ В
УЧЕБНОЙ РАБОТЕ
В учебной работе могут содержаться отдельные фрагменты программ (ли-
стинг), разработанных студентом.
Название листинга пишется в одну строку с номером, через тире, с большой
буквы, перед листингом. Точка в конце не ставится. Пример, «Листинг 1.7 —
Процедура открытия программы».
При ссылке на отдельные строки программы они нумеруются в порядке воз-
растания с шагом 10. После ссылки на листинг в фигурных скобках привод ятся
номера строк. Пример «Листинг 3.2 {30, 50, 140}», «Листинг 3.2 {20- 80}».
Листинг оформляется в рамку (рис. 4.1-4.2).
Рисунок 4.1. Пример 1 оформления листинга
Рисунок 4.2. Пример 2 оформления листинга
28
Параметры оформления листинга представлены в табл. 4.1.
Таблица 4.1. Параметры оформления листинга
Листинг
Надпись листинга
Шрифт Шрифт
Шрифт Times New Roman
Начертание Курсив
Размер 12 пт
Цвет текста Авто (черный)
Подчеркивание нет
Видоизменение нет
Интервал
Масштаб 100%
Интервал Обычный
Смещение Нет
Анимация Вид Нет
Абзац Отступы и интервалы
Выравнивание По левому краю
Отступ слева 0 см
Отступ справа 0 см
Первая строка нет
Интервал перед 6 мм
Интервал после 0 мм
Междустрочный Одинарный
Положение на странице Разбивка на страницы Не отрывать от следующего
С новой страницы
Содержание листинга
Шрифт Шрифт
Шрифт Courier New
Начертание Обычный
Размер 10 пт
Цвет текста Авто (черный)
Подчеркивание Нет
Видоизменение нет
Интервал
Масштаб 100%
Интервал Обычный
Смещение Нет
Анимация Вид Нет
Абзац
Отступы и интервалы
Выравнивание По левому краю
Отступ слева 0 см
Отступ справа 0 см
Первая строка 0 см
Интервал перед 0 мм
Интервал после 0 мм
Междустрочный Одинарный
29
Основной текст (строка) после листинга печатается с интервалом перед 6
мм.
Весь текст программы целесообразно выносить в приложени е.
30
5. ОФОРМЛЕНИЕ СПИСКА ИСПОЛЬЗОВАННЫХ
ИСТОЧНИКОВ В УЧЕБНОЙ РАБОТЕ
Все заимствованные части учебной работы (автором которых не является
студент) должны быть сопровождены ссылкой на источник , тип ссылки —
затекстовая (см. ГОСТ Р 7.0.5- 2008). Список должен содержать сведения об
источниках, использованных при составлении учебной работы [1].
Список использованных источников должен включать библиографические
записи на документы, использованные при составлении учебной работы, ссылки
на которые оформляют арабскими цифрами в квадратных скобках.
Сведения об источниках следует располагать в порядке появления ссылок
на источники в тексте учебной работы и нумеровать арабскими цифрами с
точкой и печатать с абзацного отступа в 1,25 см.
При оформлении раздела СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ
на первой строке листа печатается соответствующее наименование р аздела,
отформатированное по параметрам для заголовка первого уровня.
Для учебных работ вида курсовой работы или отчета по практике список
использованных источников делить на разделы не требуется. Требованиями к
источникам в данном случае являются следующие:
• количество источников от 5 до 7;
• год издания источника — за последние 5 лет к моменту написания и
представления учебной работы (Приложение Д, рис. Д.1).
В случае выпускной квалификационной рабо ты список использованных
источников делится на разделы, в каждом и которых должно быть представлено
не менее 10 источников, годом издания не больше, чем 5 лет к моменту защиты
выпускной квалификационной работы.
Параметры оформления заголовков разделов в списке использованных
источников представлены в табл. 5.1.
Внутри раздела источники распределяются в порядке упоминания их в
выпускной квалификационной работе и нум еруются (рис. 5.1). В данном случае
номер источника будет состоять из номера разд ела, к которому он относится, и
номера по порядку.
ики следует давать в виде
арабских цифр, заключенных в квадратные скобки, указывающих порядковый
номер источника по списку, например, [1], [2, 3], [1.5], [2.18].
В случае цитирования указываются страницы книги, статьи или другого
источника, из которых взята цитата, например, [2.18, c. 21-25].
31
Таблица 5.1. Параметры оформления заголовков разделов
в списке использованных источников
Параметр Значение
Шрифт
Шрифт Times New Roman
Начертание Обычный
Подчеркивание нет
Видоизменение Все прописные
Размер 14 пт
Цвет текста Авто (черный)
Абзац
Выравнивание По центру
Первая строка нет
Отступ слева 1,25 см.
Отступ справа нет
Интервал перед 6 мм
Интервал после 6 мм
Междустрочный интервал Полуторный
Положение на странице Не отрывать от следующего
Рисунок 5.1. Пример оформления списка использованных источников с делением на
разделы
32
На рис. 5. 2 приведен пример основного текста учебной работы со ссылкой
на источник.
Рисунок 5.2. Пример оформления ссылок в тексте учебной работы
На рис. 5. 3 приведен пример основного текста учебной работы со ссылкой
на источник при цитировании. При цитировании цитируемая фраза ставится в
кавычки.
Рисунок 5.3. Пример оформления ссылок в тексте при цитировании.
33
В основном тексте ВВЕДЕНИЯ и ЗАКЛЮЧЕНИЯ ссылки на
источники не указываются.
Более подробно порядок оформления различных источников представлен в
ГОСТ 7.32 — 2017 Система стандартов по информации, библиотечному и
издательскому делу. Отчет о научно -исследовательской работе. Структура и
правила и оформления. Приложение Е на странице 26 указанного документа.
34
6. ОФОРМЛЕНИЕ ПРИЛОЖЕНИЙ В УЧЕБНОЙ РАБОТЕ
яющий текст учебной работы, допускается помещать в
ие учебной работы а
последующих ее листах.
иложения могут выноситься:
• ом, так и
ия;
• уемого объекта
ия;
• асчеты;
• сложные алгоритмы;
• аботы;
• тов;
• тов;
• экранные формы инормацинной системы;
• листинги программ;
• оизводство
ии).
мата А4. Допускается
мата A3 по ГОСТ 2.301.
В учебной работе приложение может быть одно или несколько.
В случае, если в учебной работе будет только одно приложение , т о н а
следующем листе после списка использованных источников заголовком первого
уровня оформляется заголовок ПРИЛОЖЕНИЕ. И на этом же листе размещается
необходимый дополняющий материал (рис. Д.1, Приложение Д).
В случае необходимости оформить несколько приложений в учебной работе
их а я с А , з а
ﮦ «Приложение А».
ь
ия в
ой текст» (рис.
6.1).
ием
ого стилем
я».
35
Рисунок 6.1. Пример оформления раздела ПРИЛОЖЕНИЯ
а
ﮦ «Приложение А.1», «Приложение А.2», если они связаны по
смыслу.
ый по
ой текст» (рис. 6.2).
Рисунок 6.2. Пример оформления отдельного приложения в составе раздела
ПРИЛОЖЕНИЯ
36
Таблицы и иллюст рации, соде ржащиеся в п риложении, нумеруются
аналогично таблицам и рисунк а м в о сновном тексте учебной работы.
Иллюстрации каждого пр иложения обоз начают отдель ной нумерацией
арабскими циф рами с добавлен ием пе ред циф рой обоз начения приложе ния,
например, «… представлено на Рисунке Б.1», «… отражен в таблице В.1».
В тексте докумен та на все п риложения должн ы быть да ны ссылки.
Приложения располагают в порядке ссылок на них в тексте учебной работы.
При ссылке следует писать слово «П риложение» с большой буквы с
указанием порядкового номера, например «…представлено в Приложении Б».
Перечень материала, оформляемого в виде приложения, определяется
обучающимся совместно с руководителем на основе методических
рекомендаций по курсовой работе, методических рекомендаций по подготовке
отчета по практике, методических рекомендаций по написанию ВКР.
Применительно к ВКР бакалавра или магистра обязательным приложением
к ней является приложение под названием Графический материал, который
представляет собой слайды презентации с основными результатами,
полученными в ходе написания ВКР.
37
СПИСОК ИСТОЧНИКОВ И ЛИТЕРАТУРЫ
1. ГОСТ 7.32 — 2017 Система стандартов по информации,
библиотечному и издательскому делу. Отчет о научно- исследовательской
работе. Структура и правила и оформления — URL:
https://www.rea.ru/ru/org/managements/orgnirupr/Documents/gost_7.32 -2017.pdf
(дата обращения 20.11.2022)
38
ПРИЛОЖЕНИЕ А
Рисунок А.1. Общий вид титульного листа ВКР
Рисунок А.2. Общий вид титульного листа курсовой работы
39
ПРИЛОЖЕНИЕ Б
Рисунок Б.1. Общий вид одностороннего задания на курсовую работу
Рисунок Б.2. Общий вид двустороннего задания на практику
40
Рисунок Б.3. Общий вид двустороннего задания на ВКР (лицевая сторона)
Рисунок Б.4. Общий вид задания на ВКР (оборотная сторона и окончание задания )
41
ПРИЛОЖЕНИЕ В
Рисунок В.1. Пример недопустимой ситуация в учебной работе, полупустая страница при условии,
что подраздел еще не закончился
42
ПРИЛОЖЕНИЕ Г
Рисунок Г.1. Пример 1 неправильного использования страницы с альбомной
ориентацией
Рисунок Г.1. Пример 2 неправильного использования страницы с альбомной
ориентацией
43
Рисунок Г.3. Неверное представление таблицы в учебной работе
44
ПРИЛОЖЕНИЕ Д
Рисунок Д.1. Пример оформления списка использованных источников без деления на
разделы
45
ПРИЛОЖЕНИЕ Е
Рисунок Е.1. Оформление ПРИЛОЖЕНИЯ в учебной работе
46
СВЕДЕНИЯ ОБ АВТОРАХ
Бергер Екатерина Геннадьевна, к.э.н., доцент кафедры практической и при-
кладной информатики Института информационных технологий
Кириллина Юлия Владимировна, к.э.н., доцент, доцент кафедры практиче-
ской и прикладной информатики Института информационных технологий
Лагунова Анна Дмитриевна, к.э.н., доцент кафедры практической и при-
кладной информатики Института информационных технологий
AI-Docs_WriteHuman/docs/schemes.md
+272
View File
@@ -0,0 +1,272 @@
# Схемы и диаграммы
В отчёте блок кода с языком диаграммы превращается в **Рисунок** (PNG или SVG). PNG руками экспортировать не нужно: md2gost вызывает PlantUML (jar / Kroki), локальный Mermaid (браузер / QuickJS), локальный IDEF0 (Pillow) или DFD через [data-flow-diagram](https://github.com/pbauermeister/dfd) (вшитый / системный Graphviz или Kroki).
## Синтаксис в markdown
````markdown
%usecase1 Диаграмма прецедентов +listing
```uml
@startuml
actor Student
Student --> (Login)
@enduml
```
````
Широкая схема:
````markdown
%arch1 Архитектура +landscape
```uml-c4
Person(user, "Студент")
System(app, "Портал")
Rel(user, app, "логин")
```
````
| Оградка | Что происходит |
|---------|----------------|
| `` ```uml `` / `` ```plantuml `` | Сырой PlantUML (`@startuml`…`@enduml`) |
| `` ```uml-<id> `` / `` ```<id> `` | Схема из `md2gost.schemes.json` (обёртка и `!include` добавляются сами) |
| `` ```mermaid `` / `` ```mmd `` | Mermaid: браузер / QuickJS / Kroki |
| `` ```idef0 `` / `` ```uml-idef0 `` | IDEF0 (FIPS 183): локальный рендер, без PlantUML / Kroki |
| `` ```dfd `` / `` ```uml-dfd `` / `` ```data-flow-diagram `` | DFD ([pbauermeister/dfd](https://github.com/pbauermeister/dfd)): вшитый Graphviz / PATH / Kroki |
## Встроенные схемы
Файл шаблона: [`md2gost/diagrams/schemes.json`](../md2gost/diagrams/schemes.json). При первом запуске копируется в `md2gost.schemes.json` рядом с приложением. При каждом запуске встроенные схемы (`author: md2gost`) синхронизируются с шаблоном: новые id добавляются, устаревшие (например удалённый `bpmn`) убираются, содержимое обновляется. Схемы с пустым или другим `author` не трогаются. Если правите встроенную в GUI и сохраняете — `author` сбрасывается, чтобы миграция не затёрла правки.
| id | Название | Оградка |
|----|----------|---------|
| `c4` | C4 Container | `` ```uml-c4 `` / `` ```c4 `` |
| `c4context` | C4 Context | `` ```uml-c4context `` |
| `c4component` | C4 Component | `` ```uml-c4component `` |
| `usecase` | Прецеденты | `` ```uml-usecase `` / `` ```usecase `` |
| `archimate` | ArchiMate 3.2 | `` ```uml-archimate `` / `` ```archimate `` |
Для схем в теле пишите **только макросы** (Person, Rel, actor, Business_Actor, …) — без `@startuml` и без `!include`, если схема сама их добавляет.
### C4 (пример макросов)
`Person`, `System`, `System_Ext`, `Container`, `ContainerDb`, `Rel` / `Rel_R`…
### Use Case
`actor`, `usecase`, связи `-->`, `<<include>>`, `<<extend>>`.
### ArchiMate 3.2
`Business_Actor`, `Application_Service`, `Technology_Node`, `Rel_Serving` / `Rel_Realization` / `Rel_Assignment`, …
Подробно: [archimate.md](archimate.md).
Полные шпаргалки — поля `docs` и `ai-prompt` в JSON; в GUI: **Шаблоны UML** и кнопки схем в **Справка → Промпт для ИИ**.
## IDEF0 (FIPS 183)
Оградка `` ```idef0 `` (то же: `` ```uml-idef0 ``). Текст — не XML: шапка формы, боксы, стрелки ICOM (Input слева, Control сверху, Output справа, Mechanism снизу). Контекст A-0 — один бокс; декомпозиция — несколько боксов «лесенкой» и связи между ними. Рендер локальный (Pillow), без Java и Kroki.
````markdown
%a0 Контекстная диаграмма A-0
```idef0
title Распорядиться товаром
node A-0
number 1
author Кинзябулатов Рамиль
project Разработка универсальной модели торгового предприятия
date 08.02.2022
rev 31.03.2022
status PUBLICATION
context TOP
[A0] Распорядиться товаром
<- Спрос
^ Нормативная документация
-> Товар
v Персонал
```
````
Шапка/подвал NIST-формы (необязательные поля): `title`, `node`, `number`, `author`, `project`, `date`, `rev`, `status` (`WORKING` / `DRAFT` / `RECOMMENDED` / `PUBLICATION`), `context` (для A-0 — `TOP`), `used_at`, `reader`, `reader_date`, `notes`, `purpose`, `viewpoint`, `page`, `form` (`kit` по умолчанию, `plain` — без рамки).
Бокс: `[A0] Имя` или `box A0 Имя`. Стрелки к последнему боксу: `<-` / `in` вход, `^` / `control` управление, `->` / `out` выход, `v` / `mech` механизм. Явно: `A0 <- Спрос`.
Декомпозиция A0 (3 бокса, развилка, O→C, ICOM на рамке):
````markdown
%a0 Декомпозиция A0
```idef0
title Распорядиться товаром
node A0
number 2
author Кинзябулатов Рамиль
project Разработка универсальной модели торгового предприятия
date 08.02.2022
rev 31.03.2022
status PUBLICATION
context A-0
purpose Обеспечить наличие товара и его отпуск покупателю
viewpoint Руководитель торгового предприятия
[A1] Принять и оценить спрос
[A2] Закупить и хранить
[A3] Отгрузить товар
A1 <- Спрос [I1]
A2 <- Предложения поставщиков [I2]
A1, A2, A3 ^ Нормативная документация [C1]
A1 ^ Ассортиментная политика [C2]
A3 ^ Условия поставки [C3]
A1 -> A2 : план закупок
A1 -> A2.C : график поставок
A2 -> A3 : товар к отгрузке
A3 -> Товар [O1]
A3 -> Акт отгрузки [O2]
A1, A2, A3 v Персонал [M1]
A2 v Склад [M2]
```
````
Подписи к стрелкам — существительные рядом со стволом, не на линии; если связь не очевидна, рисуется squiggle (FIPS 183). Длинные фразы переносятся на 2–3 строки.
Короткий каркас:
```
[A1] Принять заказ
[A2] Отгрузить
A1 <- Заявка [I1]
A1 ^ Правила [C1]
A1 -> A2 : заказ
A1 -> A2, A3 : данные
A1, A2 -> A3 : сводка
A2 -> Товар [O1]
A2 v Склад [M1]
```
Туннель (скобки IDEF0): `(in Секрет` — на границе листа, `in) Локальный` — у бокса. Вызов другой модели: `call ИмяМодели`. Сторона порта: `A1.O -> A2.C : условие`.
## DFD (data-flow-diagram / SA/RT)
Оградка `` ```dfd `` (то же: `` ```uml-dfd ``, `` ```data-flow-diagram ``, `` ```yourdon ``). Синтаксис — пакет [pbauermeister/dfd](https://github.com/pbauermeister/dfd) (ставится с md2gost, Python 3.11+). Рендер: Graphviz (`dot` / `neato`) или Kroki (`graphviz`), не Pillow.
Порядок поиска Graphviz (как у `plantuml.jar`):
1. Вшитый `md2gost/vendor/graphviz` (exe-сборка / `python scripts/fetch_graphviz.py`)
2. Кэш `%LOCALAPPDATA%\md2gost\graphviz` (GUI: **Настройки → Диаграммы → «Скачать Graphviz»**)
3. `dot` / `neato` в `PATH`
4. Локальный Kroki → `https://kroki.io` при `--diagram-fallback remote`
````markdown
%dfd0 Контекстная DFD
```dfd
style context
entity Client Клиент
entity Warehouse Склад
process System Система учёта заявок
Client --> System заявка
System --> Client статус
System --> Warehouse накладная
```
````
Ключевые слова узлов: `process`, `entity`, `store`, `control`, `channel`. Потоки: `-->`, `->>`, `<->`, сигналы `::>` / `<::`. Контекст: `style context`. Полный синтаксис — [документация Upstream](https://github.com/pbauermeister/dfd/blob/main/doc/README.md).
Декомпозиция (уровень 0):
````markdown
%dfd1 DFD уровня 0
```dfd
entity Client Клиент
entity Warehouse Склад
process Accept Принять заявку
process Register Зарегистрировать
process Ship Сформировать накладную
store Orders Заявки
Client --> Accept заявка
Accept --> Orders новая заявка
Orders --> Register данные заявки
Register --> Ship подтверждённая заявка
Ship --> Warehouse накладная
Ship --> Client уведомление
```
````
Зависимости: `data-flow-diagram` идёт с md2gost (Python ≥3.11). Без Graphviz офлайн DFD не нарисуется — либо кнопка «Скачать Graphviz» / `scripts/fetch_graphviz.py`, либо `--diagram-fallback remote` → kroki.io.
## Файл схем: поля
```json
{
"c4": {
"title": "C4 Container",
"docs": "…макросы…",
"ai-prompt": "…инструкция для ИИ…",
"includes": ["https://…/C4_Container.puml"],
"prefix": "@startuml\n",
"postfix": "\nLAYOUT_WITH_LEGEND()\n@enduml"
}
}
```
| Поле | Назначение |
|------|------------|
| `title` | Подпись в GUI |
| `docs` | Шпаргалка макросов |
| `ai-prompt` | Фрагмент для промпта ИИ |
| `includes` | Локальные `.puml` или URL |
| `prefix` / `postfix` | Обёртка вокруг тела |
| `theme` | опционально `!theme …` |
id схемы: латиница, цифры, `_`; начинается с буквы.
## Слои загрузки (позже побеждает)
1. Встроенный шаблон `md2gost/diagrams/schemes.json`
2. Пользовательский файл рядом с приложением (`md2gost.schemes.json`)
3. `md2gost.schemes.json` рядом с `.md`
4. Явный путь `--schemes path.json`
## Рендер
**UML / схемы:**
1. Java + `plantuml.jar` (вшитый / `%LOCALAPPDATA%\md2gost\` / `--plantuml-jar`)
2. Локальный Kroki (`KROKI_URL` / `--kroki-url`, по умолчанию `http://localhost:8000`)
3. `https://kroki.io` при `--diagram-fallback remote` (по умолчанию)
**Mermaid:**
1. Системный Chrome / Edge (через Playwright, ничего не качаем)
2. Playwright Chromium в `%LOCALAPPDATA%\md2gost\ms-playwright` — кнопка «Скачать headless Chromium» или `md2gost --install-chromium`
3. QuickJS + mermaid.js (`mermaidx`) — офлайн без браузера
4. Локальный Kroki → `https://kroki.io` (если `--diagram-fallback remote`)
**IDEF0:** сразу Pillow (PNG, при `--diagram-format svg` ещё SVG). Java/Kroki не используются.
**DFD:**
1. [data-flow-diagram](https://github.com/pbauermeister/dfd) компилирует DSL → DOT
2. Вшитый / кэш / PATH Graphviz (`dot`, для `style context` — `neato`)
3. Локальный Kroki → `https://kroki.io` при `--diagram-fallback remote`
Формат: `--diagram-format png` (по умолчанию) или `svg`. Масштаб растра PlantUML / локального Mermaid / IDEF0: `--diagram-scale` (по умолчанию 2 — качество, размер на странице как при 1).
Кэш картинок: `{каталог_md}/.md2gost-cache/`.
Кэш includes: `md2gost.include-cache.json` + папка `include-cache/` (сброс в GUI: Настройки → Диаграммы / Шаблоны UML).
## Свои схемы
1. Меню **Шаблоны UML** — добавить / править / сохранить.
2. Или править `md2gost.schemes.json` вручную («Открыть JSON»).
3. CLI: `--schemes путь.json`.
Чтобы правка встроенной схемы не сбрасывалась при обновлении приложения, оставьте пустой `author` (GUI делает это сама при сохранении изменённой встроенной схемы).
AI-Docs_WriteHuman/docs/styles.md
+67
View File
@@ -0,0 +1,67 @@
# Кастомные стили (JSON)
Опциональный оверлей оформления поверх пресета `--type` (`mirea` или `pis_custom`).
Неуказанные поля остаются у пресета. Стили пишет конвертер в DOCX сам — вручную в шаблон добавлять не нужно.
## Как подключить
Позже побеждает (deep-merge только указанных ключей):
1. Встроенный пресет типа документа
2. `md2gost.styles.json` рядом с `.md` (если есть)
3. `--styles путь.json` или путь в GUI: **Настройки → Файлы → Стили JSON**
Файл рядом с exe при первом запуске **не создаётся**.
```bash
python -m md2gost report.md -o report.docx --type practice --styles examples/md2gost.styles.json
```
Пример: [`examples/md2gost.styles.json`](../examples/md2gost.styles.json).
## Схема
Два блока. Неизвестный ключ или имя стиля — ошибка.
```json
{
"page": {
"left_mm": 30,
"right_mm": 10,
"top_mm": 20,
"bottom_mm": 20
},
"styles": {
"Heading 1": {
"alignment": "center",
"size_pt": 14,
"all_caps": true
}
}
}
```
### `page`
| Ключ | Единица | Смысл |
|------|---------|--------|
| `left_mm` / `right_mm` / `top_mm` / `bottom_mm` | мм | Поля страницы |
### Имена стилей
`Normal`, `Heading 1`, `Heading 2`, `Heading 3`, `Caption Figure`, `Caption Table`, `Название таблицы`, `Caption Listing`, `Caption`, `Code`, `Table Text`, `Bibliography`, `Bibliography Heading`, `toc 1`, `toc 2`, `toc 3`, `Footer`, `Hyperlink`, `FollowedHyperlink`, `Space After Table`.
### Поля стиля
| Ключ | Тип / значения |
|------|----------------|
| `font_name` | строка |
| `size_pt` | число (pt) |
| `bold`, `italic`, `all_caps`, `underline` | bool |
| `alignment` | `left` \| `center` \| `justify` |
| `first_line_indent_cm`, `left_indent_cm`, `right_indent_cm` | см |
| `space_before_mm`, `space_after_mm` | мм |
| `line_spacing` | `1.0` \| `1.5` |
| `page_break_before`, `keep_with_next`, `widow_control` | bool |
Не в JSON: табы оглавления (считаются от ширины полосы), отступы списков, формулы из шаблона, цвет (всегда чёрный).
AI-Docs_WriteHuman/docs/title.md
+187
View File
@@ -0,0 +1,187 @@
# Автотитульник
md2gost умеет **сам собрать титульный лист** из вшитого шаблона `TitleTemplate.docx`, подставив институт, кафедру, дисциплину, преподавателя, номер работы, ФИО и группу.
Готовый чужой DOCX титула (`--title` / «Настройки → Файлы → Титульный лист») по-прежнему работает и **полностью отключает** автогенерацию.
---
## Когда титул генерируется
Автотитул **по умолчанию выключен**. Включается явно:
- CLI: `--auto-title`
- GUI: галочка **«Автотитул»**
При включённом автотитуле он собирается, если одновременно:
1. **Не задан** явный путь к титульному DOCX (`--title` пуст, в GUI поле «Титульный лист» пустое).
2. Рядом с `.md` есть файл **`info_conv.yaml`** *или* в начале Markdown есть блок **\`\`\`title**.
Если автотитул выключен или нет ни yaml, ни блока `title` — титул не вставляется (готовый DOCX по `--title` по-прежнему можно передать отдельно).
ФИО и группа **обязательны** для генерации: из профиля GUI / `md2gost.user.json` или из `--student` / `--group`. Без них конвертация с `--auto-title` завершится ошибкой с подсказкой.
---
## Быстрый сценарий (GUI)
1. Первый запуск → окно **«Данные студента»**: введите **ФИО** и **группу**, сохраните.
Позже: **Настройки → Студент…**.
2. В папке с отчётом создайте `info_conv.yaml` (см. ниже).
3. В начале `.md` при необходимости добавьте блок \`\`\`title с номером работы и годом.
4. Включите галочку **«Автотитул»** на главном окне.
5. **Не** указывайте готовый титул в «Настройки → Файлы», если хотите автогенерацию.
6. Конвертируйте как обычно — перед телом отчёта появится титул.
Профиль студента хранится в `md2gost.user.json` рядом с приложением (рядом с exe или в текущей папке при `python -m md2gost`) — тот же каталог, что и `md2gost.schemes.json`. В том же файле блок `metadata` — свойства DOCX (автор/название/примечание); GUI: **Настройки → Метаданные…**, CLI: `--doc-*`. Это не поля титульного листа.
---
## `info_conv.yaml` (данные курса / кафедры)
Файл кладётся **в тот же каталог**, что и конвертируемый `.md`. Имя строго: `info_conv.yaml`.
Пример:
```yaml
Институт: Институт информационных технологий (ИИТ)
Кафедра: Кафедра цифровой трансформации (ЦТ)
Дисциплина: Проектирование архитектуры цифровой организации
Преподаватель: Иванов Иван Иванович
Должность: старший преподаватель, кафедра ЦТ
```
Формат — плоский список `ключ: значение` (UTF-8). Вложенный YAML и списки не нужны. Строки с `#` в начале — комментарии; хвост ` # …` в значении отрезается.
Один `info_conv.yaml` удобно держать на весь семестр/дисциплину и не копировать институт с кафедрой в каждый отчёт.
---
## Блок `title` в Markdown
Опциональный блок в **начале** файла (до `# *СОДЕРЖАНИЕ`), ограда языка `title`. Перед конвертацией он **вырезается** из тела отчёта и не попадает в DOCX как код.
Типичное использование — номер работы и год:
````markdown
```title
number: 1
year: 2026
```
# *СОДЕРЖАНИЕ
[TOC]
…
````
Можно переопределить любые академические поля прямо в блоке (они сильнее yaml):
````markdown
```title
number: 3
year: 2026
discipline: Другая формулировка дисциплины
teacher: Петров П. П.
```
````
Английские ключи тоже принимаются: `institute`, `department`, `discipline`, `teacher`, `teacher_position`, `number`, `year`.
---
## Поля: куда попадают и откуда берутся
| Поле на титуле | Ключи (любой из вариантов) | Источник |
|----------------|----------------------------|----------|
| Институт | `Институт`, `Institute`, `institute`; опечатка `Инститиут` | yaml / \`\`\`title |
| Кафедра | `Кафедра`, `Department`, `department` | yaml / \`\`\`title |
| Дисциплина (в «…») | `Дисциплина`, `Discipline`, `discipline` | yaml / \`\`\`title |
| № практической работы | `number`, `номер`, `№`, `n` | \`\`\`title (иначе `1`) |
| Группа («студент группы …») | — | профиль GUI / `--group` |
| ФИО студента | — | профиль GUI / `--student` |
| Должность преподавателя | `Должность`, `должность преподавателя`, `teacher_position` | yaml / \`\`\`title |
| ФИО преподавателя | `Преподаватель`, `Преподователь`, `Teacher`, `teacher` | yaml / \`\`\`title |
| Год («Москва … г.») | `year`, `год` | \`\`\`title (иначе текущий календарный год) |
Строка «ОТЧЁТ ПО ПРАКТИЧЕСКОЙ РАБОТЕ» и шапка МИРЭА в шаблоне **не** заполняются из переменных — это фиксированный текст шаблона.
ФИО/`группа` из yaml или \`\`\`title **игнорируются** (даже если написать `Студент:` / `Группа:`) — студент всегда из профиля или CLI.
---
## Приоритет слияния
```
Академические поля: info_conv.yaml < ```title (блок сильнее)
Студент / группа: md2gost.user.json < --student / --group
Явный титул DOCX: --title / путь в GUI → генератор не вызывается
```
`year` без значения → текущий год. `number` без значения → `1`.
---
## CLI
```bash
# автотитул выкл. по умолчанию — только тело отчёта
python -m md2gost report.md -o report.docx
# включить автотитул (yaml + профиль из md2gost.user.json)
python -m md2gost report.md -o report.docx --auto-title
# ФИО и группа на один прогон
python -m md2gost report.md --auto-title --student "Тарасов Игорь Алексеевич" --group ИНБО-31-23
# свой готовый титул — автогенерация не используется
python -m md2gost report.md --title title.docx
```
---
## Пример структуры папки
```
Отчет_практики/
info_conv.yaml ← институт, кафедра, дисциплина, препод
report_pr1.md ← в начале ```title с number/year
figures/
…
```
`report_pr1.md`:
````markdown
```title
number: 1
year: 2026
```
# *СОДЕРЖАНИЕ
[TOC]
# *ВВЕДЕНИЕ
…
````
---
## Частые вопросы
**Титул не появился.**
Проверьте: включён ли `--auto-title` / галочка «Автотитул»; нет ли пути в «Титульный лист» / `--title`; есть ли `info_conv.yaml` или \`\`\`title; заполнены ли ФИО и группа.
**Не тот номер работы.**
Задайте `number:` в \`\`\`title — из yaml номер не читается (только из блока или дефолт `1`).
**Нужен другой шаблон вёрстки.**
Сейчас слоты привязаны к bundled `TitleTemplate.docx`. Чужой макет — собирайте титул вручную и передавайте через `--title`.
**Задание (бланк).**
Автотитул не заменяет бланк задания: по-прежнему `--assignment` / «Бланк задания» в GUI.
**Где лежит профиль.**
`md2gost.user.json` рядом с приложением (см. каталог схем). Не коммитьте его с чужими ФИО в общие репозитории отчётов — это локальные данные студента.
AI-Docs_WriteHuman/docs/types.md
+66
View File
@@ -0,0 +1,66 @@
# Типы документов
Задаётся флагом `--type` / выбором в GUI. Профили: [`md2gost/profiles.py`](../md2gost/profiles.py).
## Сводка
| Тип | Стили | Нумерация объектов | Источники | Структура |
|-----|--------|-------------------|-----------|-----------|
| `practice` | МИРЭА | по разделам (1.1, 2.1) | 5–7, ≤5 лет | Введение, разделы, заключение, список, приложения |
| `coursework` | МИРЭА | по разделам | 5–7, ≤5 лет | то же |
| `vkr` | МИРЭА | по разделам | ≥10 в **каждом** разделе списка, ≤5 лет | + приложение «Графический материал»; ссылки `[1.5]` |
| `PIS_custom` | ПИС | сквозная (1, 2, 3) | не требуются | H1 = практические работы; без введения/заключения по умолчанию |
| `APID_coursework` | МИРЭА | по разделам | 7–20, ≤5 лет | обязательные главы/пункты АПИД (см. ниже) |
## coursework / practice
Спецразделы с `*`, нумерованная основная часть. В DOCX: H1 слева с отступом (кроме СОДЕРЖАНИЕ / СПИСОК — по центру).
Проверка: `--check` / `--strict`.
## vkr
- Список источников **с разделами**; в каждом ≥10 записей.
- Ссылки вида `[1.5]`, при цитировании `[2.18, c. 21-25]`.
- Обязательное приложение с текстом «Графический материал» в названии.
## PIS_custom
Итоговый отчёт по практическим работам.
```markdown
# *СОДЕРЖАНИЕ
[TOC]
# Практическая работа №1. Название работы
## Цель работы
## Ход работы
## Выводы
# Практическая работа №2. …
```
- H1 **без** `*` (кроме СОДЕРЖАНИЕ): в DOCX — ПРОПИСНЫМИ по центру.
- H2 с абзацным отступом.
- Титул («Отчёт по практическим работам …») — отдельный DOCX: `--title title.docx`.
Пример: [`examples/pis_custom.md`](../examples/pis_custom.md).
Промпт: [`prompts/generate-pis-custom-report.md`](../prompts/generate-pis-custom-report.md).
## APID_coursework
Курсовая «Архитектура приложений и данных» (методичка Аншиной/Лагуновой). Оформление как у `coursework`, плюс проверка заголовков:
1. Теоретические аспекты …
2. Прикладные аспекты …
- 2.1 Описание проекта …
- 2.2 Описание роли …
- 2.3 Описание архитектуры …
- 2.4 Варианты развития архитектуры …
Источники: 7–20.
```bash
python -m md2gost report.md -o report.docx --type APID_coursework --check --title title.docx --assignment assignment.docx
```
AI-Docs_WriteHuman/docs/word2md.md
+46
View File
@@ -0,0 +1,46 @@
# Импорт Word → Markdown (word2md)
Обратный пайплайн: **DOCX → Markdown** в диалекте md2gost. Удобно, если отчёт уже набран в Word (или собран md2gost раньше), а дальше править удобнее в `.md`.
Это **эвристический** импорт, не lossless round-trip: исходник UML/Mermaid, `%id` из исходного md и язык fence у листинга из DOCX не восстанавливаются.
## Запуск
```bash
python -m word2md report.docx -o report.md
word2md report.docx
python -m md2gost report.docx -o report.md # тот же импорт через md2gost
```
В GUI: перетащите `.docx` или кнопка **«Импорт DOCX→MD»**.
Картинки пишутся в каталог `<stem>_media/` рядом с `.md` (или `--media-dir`).
| Флаг | Смысл |
|------|--------|
| `-o` / `--output` | путь к `.md` |
| `--media-dir` | каталог картинок |
| `--keep-toc-pages` | не выкидывать строки содержания Word (по умолчанию только `[TOC]`) |
| `--pagebreaks` | писать `---` на разрывах страниц |
## Что распознаётся
- заголовки `Heading N` / спецразделы → `# *ВВЕДЕНИЕ`, `# 1 …`
- содержание → `# *СОДЕРЖАНИЕ` + `[TOC]` (поле TOC и строки `toc N` отбрасываются)
- подписи `Рисунок N — …`, `Таблица N`, `Листинг N` (+ «Продолжение…» склеивается)
- таблицы с merge → `^` / `>`
- листинги стиля `Code`
- формулы (таблица Formula / OMML) → `$$…$$`
- библиография `[1]: …`, ссылки `[1]` в тексте
- второй проход: `Рисунок 1.1` → `@Рисунок:fig1_1` (если номер известен по подписи)
Титул и бланк задания до первого H1/спецраздела пропускаются. Колонтитулы не импортируются.
## Ограничения
- Нет восстановления PlantUML / Mermaid (только PNG/JPEG из файла)
- OMML → формула — best-effort, не идеальный LaTeX
- Надписи, SmartArt, сноски, плавающие рисунки — пропуск с записью в лог
- Титул, свёрстанный большой таблицей, может попасть в поток, если walker уже «стартовал» — обычно титул до первого Heading пропускается
После импорта имеет смысл прогнать `python -m md2gost report.md --check`.