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
AIV2/README.md → AI-Docs_WriteHuman/Readme.MD
+6 -16
View File
@@ -1,12 +1,6 @@
# AIV2/ — промпты и документация для нейросетей
# Промпты и документация для нейросетей
Исправленная копия набора `ai/`. Добавлены правила, которые `--check` не ловит, а преподаватель — да: собственно-научный стиль, запрет «Практическая работа» в названии пункта, полное наименование до аббревиатуры, группировка ссылок `[1, 2]`, запрет таблицы реквизитов, читаемые иерархические схемы, границы пунктов задания, критический разбор фрагмента **до** сдачи следующей практики.
**Главное правило: файл из `AIV2/prompts/` — это целиком промпт.** В нём нет ни заголовка «скопируйте текст ниже», ни разделителей, ни инструкций для человека. Открыл файл, выделил всё, вставил в модель — работает. Инструкции для человека живут только в этом README.
Файлы из `AIV2/context/` — справочники: их дают модели как дополнительный контекст, когда нужна точность в узком месте. Файлы из `AIV2/examples/` — эталонные документы, проходящие проверку `--check` без замечаний; их дают как образец.
---
**Данная документация в первую очередь предназначена для человека.**
## 1. Что где лежит
@@ -46,11 +40,11 @@
Оба файла проверены: `--check-only` не даёт ни одного замечания, сборка DOCX проходит на локальном рендере без интернета.
---
## 2. Рецепты
Что вставлять в модель под конкретную задачу.
Какой файл вставлять в диалог под конкретную задачу.
| Задача | Что даёшь модели |
|--------|------------------|
@@ -76,9 +70,7 @@
Следующим сообщением после промпта дай модели заполненный блок:
```text
Тип работы: coursework
Тема: Разработка модуля учёта заявок на техническое обслуживание
Год сдачи: 2026
Дисциплина: Проектирование информационных систем
Объект: процесс приёма и исполнения заявок на обслуживание оборудования
@@ -147,8 +139,6 @@ python -m md2gost report.docx --check-pages
## 7. Отношение к остальному репозиторию
Каталоги `docs/` и `prompts/` в корне репозитория остаются как есть: на них ссылается встроенная справка приложения (**Справка → Документация**, **Справка → Промпт для ИИ**). Каталог `AIV2/` — исправленный набор относительно `ai/`; в приложение ничего не ломает.
Каталоги `docs/` и `prompts/` в корне репозитория остаются как есть: на них ссылается встроенная справка приложения (**Справка → Документация**, **Справка → Промпт для ИИ**).
Для отчётов ПАЦО не используй `ai/prompts/report-pis.md` как основной промпт: он заставляет писать «Практическая работа №N» и дробить пункт на «Цель / Ход / Выводы».
Источник истины по возможностям конвертера — код в `md2gost/`; справочники в `AIV2/context/` собраны по нему, а не по старой документации.
Источник истины по возможностям конвертера — код в `md2gost/`; справочники в `AI-Docs_WriteHuman/context/` собраны по нему, а не по старой документации.
AIV2/context/academic-style.md → AI-Docs_WriteHuman/context/academic-style.md
View File
AIV2/context/archimate.md → AI-Docs_WriteHuman/context/archimate.md
View File
AIV2/context/checker.md → AI-Docs_WriteHuman/context/checker.md
View File
AIV2/context/cli.md → AI-Docs_WriteHuman/context/cli.md
View File
AIV2/context/diagrams.md → AI-Docs_WriteHuman/context/diagrams.md
View File
AIV2/context/org-hierarchy.md → AI-Docs_WriteHuman/context/org-hierarchy.md
View File
AIV2/context/syntax.md → AI-Docs_WriteHuman/context/syntax.md
View File
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`.
AIV2/examples/coursework.md → AI-Docs_WriteHuman/examples/coursework.md
View File
AIV2/examples/pis-report.md → AI-Docs_WriteHuman/examples/pis-report.md
View File
AIV2/prompts/core-md2gost.md → AI-Docs_WriteHuman/prompts/core-md2gost.md
View File
AIV2/prompts/from-word.md → AI-Docs_WriteHuman/prompts/from-word.md
View File
AIV2/prompts/report-apid.md → AI-Docs_WriteHuman/prompts/report-apid.md
View File
AIV2/prompts/report-mirea.md → AI-Docs_WriteHuman/prompts/report-mirea.md
View File
AIV2/prompts/report-paco.md → AI-Docs_WriteHuman/prompts/report-paco.md
View File
AIV2/prompts/report-pis.md → AI-Docs_WriteHuman/prompts/report-pis.md
View File
AIV2/prompts/review-fix.md → AI-Docs_WriteHuman/prompts/review-fix.md
View File
AIV2/prompts/voice-human.md → AI-Docs_WriteHuman/prompts/voice-human.md
+1 -1
View File
@@ -55,7 +55,7 @@
# 6. Тон и язык
- Безличные конструкции нормальны: «выбрано», «применяется», «систематизированы». Без «я» и «мы».
- Ссылки на источники — по делу, а не в каждом абзаце. Несколько источников на один факт — `[1, 2]`, не `[1], [2]`.
- Ссылки на источники — по делу, а не в каждом абзаце. Несколько источников на один факт писать как — `[1, 2]`, не `[1], [2]`.
- Для отчёта по практикам обязателен **собственно-научный подстиль**: связный абзац, термины, без метафор. Запрещены «давит на маржу», «тянут к», «усложняется, зато», рубленые «Экономические факторы — …».
- «По-человечески» ≠ публицистика. Конкретика («3,1 млн клиентов», «ИНН 6663003127») остаётся; антитезы и разговорные глаголы — нет.
- Термины и аббревиатуры вводятся один раз с полной формой и дальше не переопределяются.
ai/README.md
-147
View File
@@ -1,147 +0,0 @@
# ai/ — промпты и документация для нейросетей
Материалы md2gost, переписанные под работу с языковыми моделями.
**Главное правило: файл из `ai/prompts/` — это целиком промпт.** В нём нет ни заголовка «скопируйте текст ниже», ни разделителей, ни инструкций для человека. Открыл файл, выделил всё, вставил в модель — работает. Инструкции для человека живут только в этом README.
Файлы из `ai/context/` — справочники: их дают модели как дополнительный контекст, когда нужна точность в узком месте. Файлы из `ai/examples/` — эталонные документы, проходящие проверку `--check` без замечаний; их дают как образец.
---
## 1. Что где лежит
### `ai/prompts/` — готовые к вставке промпты
| Файл | Когда брать | Размер |
|------|-------------|--------|
| [`core-md2gost.md`](prompts/core-md2gost.md) | нужен просто markdown в диалекте md2gost, без привязки к типу учебной работы | 12 тыс. знаков |
| [`report-mirea.md`](prompts/report-mirea.md) | отчёт по практике, курсовая, ВКР (`practice`, `coursework`, `vkr`) | 12 тыс. знаков |
| [`report-apid.md`](prompts/report-apid.md) | курсовая «Архитектура приложений и данных» (`APID_coursework`) | 10 тыс. знаков |
| [`report-pis.md`](prompts/report-pis.md) | итоговый отчёт по практическим работам (`PIS_custom`) | 7 тыс. знаков |
| [`voice-human.md`](prompts/voice-human.md) | добавка к любому из промптов выше: живой текст про предмет, а не отчёт модели о сдаче задания | 5 тыс. знаков |
| [`review-fix.md`](prompts/review-fix.md) | есть готовый `.md`, надо починить его под ТЗ (в том числе по выводу `--check`) | 8 тыс. знаков |
| [`from-word.md`](prompts/from-word.md) | есть результат импорта `word2md`, надо довести до диалекта | 6 тыс. знаков |
Промпты самодостаточны: правила диалекта в них повторяются намеренно, чтобы каждый работал в одиночку.
### `ai/context/` — справочники для догрузки
| Файл | О чём | Размер |
|------|-------|--------|
| [`syntax.md`](context/syntax.md) | полная спецификация диалекта: регулярные выражения, приоритеты, подводные камни | 16 тыс. знаков |
| [`diagrams.md`](context/diagrams.md) | все нотации схем с готовыми каркасами: PlantUML, C4, Mermaid, IDEF0, DFD | 16 тыс. знаков |
| [`archimate.md`](context/archimate.md) | ArchiMate 3.2: макросы элементов и связей, направления, viewpoints, шаблоны | 22 тыс. знаков |
| [`checker.md`](context/checker.md) | каталог замечаний `--check` с текстами сообщений и способами починки | 10 тыс. знаков |
| [`cli.md`](context/cli.md) | все ключи запуска, профили типов, конфигурационные файлы, оформление | 12 тыс. знаков |
### `ai/examples/` — эталоны
| Файл | Тип | Что демонстрирует |
|------|-----|-------------------|
| [`coursework.md`](examples/coursework.md) | `coursework` | полная структура, IDEF0, C4, ER-диаграмма, объединение ячеек, формула, листинг, два приложения, шесть источников |
| [`pis-report.md`](examples/pis-report.md) | `PIS_custom` | четыре практические работы, DFD, IDEF0, сквозные метки, расчёт нагрузки |
Оба файла проверены: `--check-only` не даёт ни одного замечания, сборка DOCX проходит на локальном рендере без интернета.
---
## 2. Рецепты
Что вставлять в модель под конкретную задачу.
| Задача | Что даёшь модели |
|--------|------------------|
| Сгенерировать курсовую или отчёт по практике | `prompts/report-mirea.md` → вторым сообщением `prompts/voice-human.md` → третьим сообщением входные данные |
| То же, но нужен упор на схемы | добавь `context/diagrams.md` перед входными данными |
| Курсовая АПИД | `prompts/report-apid.md` + `prompts/voice-human.md` + при необходимости `context/archimate.md` |
| Отчёт по практическим работам ПИС | `prompts/report-pis.md` + входные данные |
| Дописать раздел в существующий отчёт | `prompts/core-md2gost.md` + `prompts/voice-human.md` + текущий `.md` целиком + что дописать |
| Починить файл по замечаниям проверки | `prompts/review-fix.md` + вывод `--check` + `.md` целиком |
| Довести импорт из Word | `prompts/from-word.md` + результат `word2md` |
| Нарисовать одну схему | `context/diagrams.md` (или `context/archimate.md`) + описание того, что надо изобразить |
| Разобраться, почему конвертер ругается | `context/checker.md` + текст ошибки |
| Модель путается в синтаксисе | добавь `context/syntax.md` |
| Нужен образец «как должно выглядеть» | добавь `examples/coursework.md` |
Если контекст модели ограничен, порядок приоритета такой: промпт → входные данные → эталон → справочник. Справочник — первое, чем можно пожертвовать.
---
## 3. Шаблон входных данных
Следующим сообщением после промпта дай модели заполненный блок:
```text
Тип работы: coursework
Тема: Разработка модуля учёта заявок на техническое обслуживание
Год сдачи: 2026
Дисциплина: Проектирование информационных систем
Объект: процесс приёма и исполнения заявок на обслуживание оборудования
Что уже известно:
- склад обрабатывает около 400 отгрузок в сутки
- заявки принимаются по телефону, фиксируются в электронных таблицах
- нужна интеграция со справочником оборудования по REST
Требования руководителя:
- обязательны диаграмма прецедентов и модель данных
- три раздела основной части
Литература: если есть свой список — приведи его здесь; иначе модель подберёт сама
Черновик: приложи имеющийся текст, если он есть
```
Чем конкретнее «что уже известно», тем меньше выдумок в тексте. Числа, названия и ограничения — самое ценное, что можно дать.
---
## 4. Полный цикл работы
```bash
# 1. Сохранить ответ модели как report.md
# 2. Проверить по ТЗ
python -m md2gost report.md --check-only --type coursework
# 3. Если есть замечания — отдать их модели вместе с файлом
# и промптом ai/prompts/review-fix.md, сохранить результат, вернуться к шагу 2
# 4. Собрать документ
python -m md2gost report.md -o report.docx --type coursework --check --strict
# 5. Проверить вёрстку готового файла (Windows + Word + pywin32)
python -m md2gost report.docx --check-pages
```
Автотитул при необходимости: положить рядом `info_conv.yaml`, добавить в начало `.md` блок ` ```title ` с номером работы и годом, запустить с `--auto-title --student "…" --group "…"`. Подробности — в [`context/cli.md`](context/cli.md).
---
## 5. Куда вставлять промпт
| Инструмент | Куда |
|------------|------|
| ChatGPT, Claude | системная инструкция проекта либо первое сообщение диалога |
| Cursor | правила для ИИ, либо первое сообщение агенту |
| GitHub Copilot Chat | контекст чата |
| API | роль `system` |
Промпты рассчитаны на модель с рассуждением и длинным контекстом: они содержат чек-листы самопроверки, которые слабые модели игнорируют. Если результат не проходит `--check` с первого раза — это нормальный рабочий цикл, для него и сделан `review-fix.md`.
---
## 6. Что модель делать не должна
Проверка `--check` не ловит фактические ошибки и выдуманные источники. Перед сдачей обязательно вычитай:
- **список литературы** — модели склонны придумывать издания, ISBN и число страниц. Промпты запрещают это прямо, но проверять всё равно нужно;
- **числа и названия** — если ты их не давал, модель их сочинила;
- **соответствие теме** — структура может быть безупречной при пустом содержании.
---
## 7. Отношение к остальному репозиторию
Каталоги `docs/` и `prompts/` в корне репозитория остаются как есть: на них ссылается встроенная справка приложения (**Справка → Документация**, **Справка → Промпт для ИИ**). Каталог `ai/` — самостоятельный набор, переписанный под подачу в модели, и ничего в приложении не ломает.
Источник истины по возможностям конвертера — код в `md2gost/`; справочники в `ai/context/` собраны по нему, а не по старой документации.
ai/context/archimate.md
-514
View File
@@ -1,514 +0,0 @@
# ArchiMate 3.2 для md2gost — рабочий справочник
Как корректно генерировать диаграммы ArchiMate® 3.2 в PlantUML для отчётов md2gost. Версия языка — только **3.2**. ArchiMate® — товарный знак The Open Group; этот текст — учебная выжимка, не копия спецификации.
---
## 1. Как рисовать
Оградка ` ```uml-archimate ` или ` ```archimate `. В теле — **только макросы**: ни `@startuml`, ни `@enduml`, ни `!include` (их подставит схема).
~~~markdown
Слоистая архитектура портала приведена на @Рисунок:arch_layered.
%arch_layered Слоистая архитектура портала +landscape
```uml-archimate
LAYOUT_TOP_DOWN()
Business_Actor(student, "Студент")
Business_Process(enroll, "Подача заявки")
Application_Service(portalSvc, "Сервис приёма заявок")
Application_Component(portal, "Веб-портал")
Rel_Assignment(student, enroll)
Rel_Serving(portalSvc, enroll)
Rel_Realization(portal, portalSvc)
```
~~~
Широкие схемы (Layered, Application Cooperation) почти всегда с `+landscape`. Флаг `+listing` добавит исходник схемы отдельным Листингом.
Формат макроса: `Категория_Элемент(alias, "Подпись")`. Alias — латиница (`student`, `crm`); нельзя `end`, `start`, `group`. Подписи русские, в кавычках; длинные переносятся через `\n`.
---
## 2. Каркас языка
**Три core-слоя:**
| Слой | Что показывает |
|------|----------------|
| Business | бизнес-сервисы для клиентов, процессы и акторы, которые их реализуют |
| Application | прикладные сервисы и приложения, поддерживающие бизнес |
| Technology | обработка, хранение, сети, а также физический мир |
Плюс слой Strategy, слой Implementation & Migration и аспект Motivation.
**Четыре аспекта:**
| Аспект | Роль | Примеры |
|--------|------|---------|
| Active structure | кто действует | Actor, Role, Component, Node, Device |
| Behavior | что делается | Process, Function, Interaction, Service, Event |
| Passive structure | над чем работают | Business Object, Data Object, Artifact |
| Motivation | зачем | Stakeholder, Driver, Goal, Requirement |
**Каноническая цепочка внутри слоя:**
```text
Active structure —Assignment→ internal behavior (Process / Function)
internal behavior —Realization→ Service (внешнее поведение)
Service —Serving→ потребитель (Role / Process / Component)
behavior —Access→ passive structure
```
**Два межслойных моста:** Serving (сервис предоставляет функциональность потребителю) и Realization (более конкретное реализует более абстрактное).
---
## 3. Элементы → макросы
### Motivation
| Элемент | Макрос | Определение |
|---------|--------|-------------|
| 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` | относительная ценность концепта |
### Strategy
| Элемент | Макрос | Определение |
|---------|--------|-------------|
| Resource | `Strategy_Resource` | актив, которым владеют или управляют |
| Capability | `Strategy_Capability` | способность активной структуры |
| Value Stream | `Strategy_ValueStream` | последовательность активностей, создающая результат для клиента |
| Course of Action | `Strategy_CourseOfAction` | план настройки capabilities и resources под цель |
### Business
| Элемент | Макрос | Аспект | Определение |
|---------|--------|--------|-------------|
| Business Actor | `Business_Actor` | active | сущность, способная выполнять поведение |
| Business Role | `Business_Role` | active | ответственность за поведение |
| Business Collaboration | `Business_Collaboration` | active | агрегат двух и более активных структур |
| Business Interface | `Business_Interface` | active | точка доступа к бизнес-сервису |
| Business Process | `Business_Process` | behavior | последовательность поведения к результату |
| Business Function | `Business_Function` | behavior | набор поведения по компетенциям и ресурсам |
| Business Interaction | `Business_Interaction` | behavior | коллективное поведение участников |
| 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 | набор сервисов и объектов вместе с контрактом |
### Application
| Элемент | Макрос | Аспект | Определение |
|---------|--------|--------|-------------|
| Application Component | `Application_Component` | active | модульная инкапсуляция прикладной функциональности |
| Application Collaboration | `Application_Collaboration` | active | агрегат прикладных активных структур |
| Application Interface | `Application_Interface` | active | точка доступа к прикладным сервисам |
| Application Function | `Application_Function` | behavior | автоматизированное поведение компонента |
| Application Interaction | `Application_Interaction` | behavior | коллективное поведение компонентов |
| Application Process | `Application_Process` | behavior | последовательность прикладного поведения |
| Application Event | `Application_Event` | behavior | изменение состояния приложения |
| Application Service | `Application_Service` | behavior | внешне видимое прикладное поведение |
| Data Object | `Application_DataObject` | passive | данные, структурированные для обработки |
### Technology и Physical
| Элемент | Макрос | Определение |
|---------|--------|-------------|
| Node | `Technology_Node` | вычислительный или физический ресурс, хостящий другие |
| Device | `Technology_Device` | физический ИТ-ресурс |
| System Software | `Technology_SystemSoftware` | ПО среды исполнения или хранения |
| Technology Collaboration | `Technology_Collaboration` | агрегат технологических активных структур |
| Technology Interface | `Technology_Interface` | точка доступа к технологическим сервисам |
| Path | `Technology_Path` | связь между технологическими структурами для обмена |
| Communication Network | `Technology_CommunicationNetwork` | структуры передачи данных |
| Technology Function | `Technology_Function` | набор технологического поведения |
| Technology Process | `Technology_Process` | последовательность технологического поведения |
| Technology Interaction | `Technology_Interaction` | коллективное технологическое поведение |
| Technology Event | `Technology_Event` | изменение технологического состояния |
| Technology Service | `Technology_Service` | внешне видимое технологическое поведение |
| Artifact | `Technology_Artifact` | данные или файл, используемый при разработке и эксплуатации |
| Equipment | `Physical_Equipment` | физические машины и инструменты |
| Facility | `Physical_Facility` | физическая структура или окружение |
| Distribution Network | `Physical_DistributionNetwork` | сеть транспортировки материи или энергии |
| Material | `Physical_Material` | осязаемая материя или энергия |
В 3.2 Device, System Software, Facility и Equipment — **не** подтипы Node, а технологические активные структуры, связанные с Node композицией или агрегацией.
### Implementation & Migration
| Элемент | Макрос | Определение |
|---------|--------|-------------|
| Work Package | `Implementation_WorkPackage` | серия действий с результатом в сроках и ресурсах |
| Deliverable | `Implementation_Deliverable` | определённый результат work package |
| Implementation Event | `Implementation_Event` | изменение состояния при внедрении |
| Plateau | `Implementation_Plateau` | стабильное состояние архитектуры на период |
| Gap | `Implementation_Gap` | различие между двумя plateau |
### Composite и Junction
| Элемент | Макрос |
|---------|--------|
| Grouping | `Grouping` / `Other_Grouping` / `Group` |
| Location | `Other_Location` / `Business_Location` |
| And Junction | `Junction_And` |
| Or Junction | `Junction_Or` |
Grouping и Junction допустимы в любом viewpoint.
### Какой элемент поведения выбрать
| Нужно показать | Берётся |
|----------------|---------|
| последовательность шагов к результату | `*_Process` |
| группу поведения по компетенциям и ресурсам | `*_Function` |
| поведение двух и более участников | `*_Interaction` |
| внешне видимое поведение, чёрный ящик | `*_Service` |
| момент или смену состояния | `*_Event` |
Слой задаётся типом элемента, а не подписью: `Business_Process` ≠ `Application_Process` ≠ `Technology_Process`.
---
## 4. Связи
| Тип | Класс | Смысл | Макрос | Нотация |
|-----|-------|-------|--------|---------|
| Composition | structural | целое состоит из частей, часть не живёт отдельно | `Rel_Composition` | `*--` |
| Aggregation | structural | целое объединяет части, части живут отдельно | `Rel_Aggregation` | `o--` |
| Assignment | structural | ответственность, исполнение, размещение | `Rel_Assignment` | `@-->>` |
| Realization | structural | конкретное реализует абстрактное | `Rel_Realization` | `~~\|>` |
| Serving | dependency | предоставляет функциональность другому | `Rel_Serving` | `-->` |
| Access | dependency | поведение работает с пассивным элементом | `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` | `--` |
Направление раскладки: суффиксы `_Up`, `_Down`, `_Left`, `_Right` — например `Rel_Serving_Up(svc, proc)`.
### Направления связей — где чаще всего ошибаются
| Связь | Откуда → куда |
|-------|---------------|
| Serving | поставщик (обычно Service) → **потребитель** |
| Realization | более конкретное → более абстрактное |
| Composition, Aggregation | целое → часть |
| Assignment | активная структура → поведение |
| Access | поведение → **пассивный** элемент, вид read / write / read-write |
| Triggering | предшественник → следующий |
| Flow | источник → приёмник |
| Influence | влияющий → motivation-элемент, сила в подписи (`++`, `+`, `0`, `-`, `--`) |
| Specialization | специализация → общий тип |
### Правила метамодели
- Элемент может композировать или агрегировать элементы того же класса.
- Внутренние поведения одного слоя могут агрегировать друг друга (Function агрегирует Process).
- Collaboration ведёт себя как соответствующая внутренняя активная структура.
- Stakeholder связывается Association с любым элементом; остальные motivation-элементы влияют друг на друга через Influence.
- Association формально возможна между любыми классами, но применяется только когда нет более точного типа.
---
## 5. Канонические цепочки
```text
# Внутри слоя Business
Business_Actor / Business_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
Application_Component Rel_Assignment Application_Function / Process
Application_Function Rel_Realization Application_Service
Application_Service Rel_Serving Business_Process / Business_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 / App_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
# Внедрение и миграция
Implementation_WorkPackage Rel_Realization Implementation_Deliverable
Implementation_Plateau Rel_Aggregation элементы core-слоёв
Implementation_Gap Rel_Association между двумя plateau
```
### Запреты
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` там, где исполнитель — приложение.
6. Не ставить Association на все рёбра «на всякий случай».
7. Не считать Device подтипом Node без композиции или агрегации.
---
## 6. Viewpoints
**Один рисунок = один viewpoint.** Не сваливать мотивацию, бизнес, приложения и инфраструктуру на один холст (Layered — исключение, но и там ограничивай число элементов).
| Viewpoint | Фокус | Типичные элементы |
|-----------|-------|-------------------|
| Organization | структура организационных единиц | Actor, Role, Collaboration, Location |
| Application Structure | внутренняя структура приложений | Component, Interface, Data Object |
| Information Structure | данные и информация | Business Object, Representation, Data Object, Artifact |
| Technology | инфраструктура | Node, Device, System Software, Network, Path |
| Layered | обзор слоёв | Business + Application + Technology, Serving и Realization |
| Physical | физический мир | Equipment, Facility, Distribution Network, Material |
| Product | ценность продукта | Product, Contract, Service, Interface |
| Application Usage | приложения в бизнес-контексте | бизнес-процессы + прикладные сервисы |
| Technology Usage | технологии для приложений | Application + Technology services и nodes |
| Business Process Cooperation | связь процессов | Process, Event, Service, Role |
| Application Cooperation | связь приложений | Component, Service, Interface, Data, Flow |
| Service Realization | как реализованы сервисы | Service ← Process / Function ← активная структура |
| Implementation and Deployment | развёртывание | Application + Artifact + Node / Device |
| Stakeholder, Goal Realization, Requirements Realization, Motivation | мотивация | Driver, Goal, Outcome, Requirement, Constraint |
| Strategy, Capability Map, Value Stream, Resource Map | стратегия | Capability, Resource, Value Stream, Course of Action |
| Project, Migration, Implementation and Migration | внедрение | Work Package, Deliverable, Plateau, Gap |
### Макет
- Структурные схемы: `LAYOUT_TOP_DOWN()` или вложенность через `{ }`.
- Процессы слева направо: `LAYOUT_LEFT_RIGHT()` и `Rel_*_Right`.
- Layered: бизнес сверху, технологии снизу; Serving и Realization направлены вверх (`Rel_Serving_Up`).
- Выравнивание скрытыми связями: `Lay_U`, `Lay_D`, `Lay_L`, `Lay_R`.
- Вложение элементов:
```text
Business_Product(prod, "Тариф") {
Business_Service(s1, "Подключение")
Business_Contract(c1, "Оферта")
}
```
Для Service, Actor, Value и ValueStream при вложении добавляется `$nest=%true()`.
---
## 7. Готовые шаблоны
Тела для ` ```uml-archimate ` без обёртки.
### Organization
```text
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)
```
### Service Realization
```text
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)
```
### Application Cooperation
```text
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, "событие оплаты")
```
### Layered
```text
LAYOUT_TOP_DOWN()
Business_Process(sale, "Оформление заказа")
Business_Object(order, "Заказ")
Application_Service(shopSvc, "Интернет-магазин")
Application_Component(shop, "ShopApp")
Technology_Service(dbSvc, "СУБД")
Technology_Node(dbHost, "Сервер БД")
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)
```
### Requirements Realization
```text
LAYOUT_TOP_DOWN()
Motivation_Stakeholder(rector, "Ректор")
Motivation_Driver(comp, "Конкуренция вузов")
Motivation_Goal(digital, "Цифровизация приёма")
Motivation_Requirement(online, "Заявление онлайн круглосуточно")
Motivation_Constraint(fz152, "152-ФЗ")
Application_Service(portal, "Портал абитуриента")
Rel_Association(rector, comp)
Rel_Association(comp, digital)
Rel_Realization(online, digital)
Rel_Influence(fz152, online, "-")
Rel_Realization(portal, online)
```
### Implementation & Migration
```text
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, "Ввод в эксплуатацию")
Rel_Association(gap1, asIs)
Rel_Association(gap1, toBe)
Rel_Realization(wp, d1)
Rel_Triggering(d1, goLive)
Rel_Triggering(goLive, toBe)
```
### Technology Usage
```text
LAYOUT_TOP_DOWN()
Application_Component(api, "API Gateway")
Technology_Node(k8s, "Кластер Kubernetes")
Technology_Device(node1, "Рабочий узел")
Technology_SystemSoftware(os, "Linux")
Technology_CommunicationNetwork(net, "Сеть кластера")
Technology_Artifact(image, "api:1.2")
Rel_Serving_Up(k8s, api)
Rel_Composition(k8s, node1)
Rel_Composition(node1, os)
Rel_Association(node1, net)
Rel_Assignment(node1, image)
```
### Процесс с Junction
```text
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)
```
---
## 8. Антипаттерны
| Плохо | Почему | Как надо |
|-------|--------|----------|
| все связи `Rel_Association` | теряется семантика | Serving, Realization, Assignment, Access |
| `Application_Component` вместо `Business_Actor` | разные аспекты и слои | Actor и Role для людей и подразделений |
| Business Process «внутри» компонента без Assignment | слои смешаны | процесс на бизнес-слое, Serving от прикладного сервиса |
| Serving от Role к Service | направление наоборот | Service → Role или Process |
| Realization Component → Process | пропущено внутреннее поведение | Component → Function → Service |
| Flow вместо Access к Data Object | Flow — передача, Access — работа с объектом | `Rel_Access_r/w/rw` |
| один Layered на 40 элементов | нечитаемо | несколько viewpoint'ов |
| C4 `Person` или UML-класс в блоке archimate | другой язык | только макросы ArchiMate |
| `Process` без указания слоя | в 3.2 слой обязателен | `Business_Process`, `Application_Process`, `Technology_Process` |
---
## 9. Чеклист генерации
1. Версия языка 3.2, макросы с указанием слоя.
2. Оградка ` ```uml-archimate `, без `@startuml` и `!include`.
3. Выбран **один** viewpoint; 8–18 элементов на рисунок.
4. Сначала объявлены все элементы, затем все `Rel_*`.
5. Alias латиницей, подписи по-русски в кавычках.
6. Serving — от сервиса к потребителю; Realization — от конкретного к абстрактному.
7. Поведение того же слоя, что и его исполнитель по Assignment.
8. Нет C4, UML-классов, BPMN-развилок и Association «по умолчанию».
9. Перед блоком стоит `%id Название`, при широкой схеме — `+landscape`.
10. В тексте есть ссылка `@Рисунок:id`.
---
## 10. Запасной вариант без stdlib
Если библиотека ArchiMate недоступна, схему можно нарисовать в ` ```uml ` низкоуровневым ключевым словом:
~~~markdown
%arch_fallback Фрагмент архитектуры
```uml
@startuml
archimate #Business "Подача заявки" as p <<business-process>>
archimate #Application "Портал" as c <<application-component>>
c --> p
@enduml
```
~~~
Смешивать макросы и низкоуровневый `archimate` на одной схеме нельзя.
ai/context/checker.md
-165
View File
@@ -1,165 +0,0 @@
# Проверка ТЗ — полный каталог замечаний
Что именно проверяет `md2gost … --check`, с какими текстами сообщений и как чинить каждое замечание.
---
## 1. Как запускать
```bash
python -m md2gost report.md --check-only --type coursework # только проверка
python -m md2gost report.md -o out.docx --type coursework --check --strict
```
| Ключ | Поведение |
|------|-----------|
| `--check` | проверить и напечатать отчёт, документ всё равно собрать |
| `--check-only` | только проверка, DOCX не собирается, код выхода 0 |
| `--strict` | при наличии хотя бы одной ошибки вывести `Проверка ТЗ: есть ошибки (--strict)`, код выхода 1, документ не собирать |
| `--check-pages` | отдельная эвристическая проверка вёрстки готового DOCX через Microsoft Word |
Формат отчёта:
```text
Проверка ТЗ: найдено замечаний — 3
[error] structure.missing: Отсутствует обязательный раздел «ЗАКЛЮЧЕНИЕ»
[warning] ref.unused (стр. md:42): Метка «tab_cmp» объявлена, но в тексте нет ссылки @…:tab_cmp
[error] ref.ris (стр. md:57): Используйте «Рисунок», не «рис.»
```
Без замечаний: `Проверка ТЗ: замечаний нет.`
Уровни: **error** — блокирует сборку при `--strict`; **warning** — не блокирует; **heuristic** — только у проверки вёрстки, никогда не влияет на код выхода.
---
## 2. Структура документа
| ID | Уровень | Сообщение | Причина и решение |
|----|---------|-----------|-------------------|
| `structure.missing` | error | `Отсутствует обязательный раздел «{название}»` | Нет одного из: СОДЕРЖАНИЕ, ВВЕДЕНИЕ, ЗАКЛЮЧЕНИЕ, СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ. Добавить раздел `# *НАЗВАНИЕ` с содержательным текстом. Допускается написание «СПИСОК ИСПОЛЬЗУЕМЫХ ИСТОЧНИКОВ» |
| `structure.missing` | error | `Отсутствует раздел «СОДЕРЖАНИЕ»` | Профиль `PIS_custom`: нет `# *СОДЕРЖАНИЕ` |
| `structure.toc` | warning | `Нет маркера [TOC] для автособираемого содержания` | Добавить `[TOC]` прописными отдельной строкой под `# *СОДЕРЖАНИЕ` |
| `structure.toc` | **error** | `Нет маркера [TOC] для оглавления (обязательно для итогового отчёта)` | То же, но для `PIS_custom` это ошибка |
| `structure.body` | error | `Нет нумерованного раздела основной части (# заголовок без *)` | Все H1 оказались со звёздочкой. Добавить `# 1 Название` |
| `structure.graphic` | error | `Для ВКР обязательно приложение «Графический материал»` | В тексте нет подстроки «Графический материал». Добавить `## Приложение Б Графический материал` |
| `structure.practical` | error | `Нет заголовков вида «Практическая работа №N. …» (H1 без *, каждая работа — отдельный раздел)` | Профиль `PIS_custom`: каждую работу оформить как `# Практическая работа №N. Название` |
| `structure.apid` | error | `Для КР АПИД отсутствует обязательный раздел: «{название}»` | См. таблицу ниже |
### Обязательные разделы КР АПИД
Проверка ищет подстроки в тексте заголовков (регистр не важен):
| Требуемый раздел | Что должно найтись в заголовках |
|------------------|--------------------------------|
| `1. Теоретические аспекты разработки архитектуры приложений и данных: …` | «теоретическ… аспект» |
| `2. Прикладные аспекты разработки архитектуры приложений и данных …` | «прикладн… аспект» |
| `2.1 Описание проекта команды и разрабатываемого программного приложения` | «2.1» и «описание проекта» рядом |
| `2.2 Описание роли … в приложении …` | «2.2» и «описание роли» рядом |
| `2.3 Описание архитектуры программного приложения и данных для роли` | «2.3» и «архитектур» |
| `2.4 Варианты развития архитектуры программного приложения` | «2.4» и «вариант» |
---
## 3. Заголовки
| ID | Уровень | Сообщение | Причина и решение |
|----|---------|-----------|-------------------|
| `heading.numbered_special` | error | `Спецраздел «{title}» должен быть без номера: # *{title}` | H1 со спецназванием без звёздочки. Добавить `*` сразу после `# ` |
| `heading.case` | warning | `Спецраздел лучше писать ПРОПИСНЫМИ: «{TITLE}»` | «Введение» вместо «ВВЕДЕНИЕ» |
| `heading.case` | warning | `Подраздел с прописной буквы: «{Title}»` | Профиль `PIS_custom`: заголовок уровня `##` и глубже начинается со строчной буквы |
| `heading.trailing_dot` | warning | `Заголовок без точки в конце: «{title}»` | Профиль `PIS_custom`: убрать точку в конце заголовка |
Спецразделы, требующие звёздочки на уровне H1: СОДЕРЖАНИЕ, ВВЕДЕНИЕ, ЗАКЛЮЧЕНИЕ, СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ, СПИСОК ИСПОЛЬЗУЕМЫХ ИСТОЧНИКОВ, ПРИЛОЖЕНИЕ, ПРИЛОЖЕНИЯ, а также любой H1, начинающийся на «ПРИЛОЖЕН».
---
## 4. Ссылки и терминология
| ID | Уровень | Сообщение | Причина и решение |
|----|---------|-----------|-------------------|
| `ref.ris` | error | `Используйте «Рисунок», не «рис.»` | В тексте найдено «рис.» (шаблон `\bрис\.`). Заменить на `@Рисунок:id` или слово «Рисунок» |
| `ref.tabl` | error | `Используйте «Таблица», не «табл.»` | Найдено «табл.». Заменить на `@Таблица:id` или слово «Таблица» |
| `footnote` | error | `Сноски в конце страницы не допускаются` | Найдена конструкция `[^…]`. Перенести содержание в основной текст или оформить ссылкой на источник |
| `table.nopp` | error | `Графу «№ п/п» в таблицы не включают` | Найдено «№ п/п». Удалить столбец |
| `ref.unused` | warning | `Метка «{id}» объявлена, но в тексте нет ссылки @…:{id}` | Добавить в текст перед объектом предложение со ссылкой `@Тип:{id}`, заканчивающееся точкой |
| `ref.dangling` | error | `Ссылка на несуществующую метку «{id}»` | Опечатка в `id` либо отсутствие объекта с такой меткой |
Множество меток собирается из строк `^%(\w+)` и из title картинок; множество ссылок — из `@Тип:id`. Оба множества должны совпадать.
---
## 5. Источники
| ID | Уровень | Сообщение | Причина и решение |
|----|---------|-----------|-------------------|
| `cite.intro` | error | `Во разделе «ВВЕДЕНИЕ» ссылки на источники не указываются` | Убрать `[n]` из введения; то же для заключения |
| `biblio.count` | error | `Источников должно быть от {min} до {max} (сейчас {n})` | Довести число записей до нормы профиля |
| `biblio.count` | warning | `ВКР: в разделе списка «{title}» желательно ≥10 источников (сейчас {n})` | Дополнить подраздел списка |
| `biblio.count` | warning | `ВКР: список должен делиться на разделы; в каждом ≥10 источников (сейчас всего {n}, разделов нет)` | Разбить список подразделами `##` |
| `biblio.age` | error | `Источник [{n}] старше {N} лет (год {год})` | Заменить на актуальное издание или редакцию стандарта |
| `biblio.order` | warning | `Порядок источников в списке должен совпадать с порядком первого упоминания` | Перенумеровать согласованно и в тексте, и в списке |
| `biblio.missing` | error | `Ссылка [{n}] есть в тексте, но нет в списке источников` | Добавить запись `[n]: …` |
Нормы по профилям:
| Профиль | Источников | Возраст |
|---------|-----------|---------|
| `practice`, `coursework` | 5–7 | не старше 5 лет |
| `APID_coursework` | 7–20 | не старше 5 лет |
| `vkr` | не менее 10 в каждом подразделе списка | не старше 5 лет |
| `PIS_custom` | не требуются | не старше 10 лет, если список всё же есть |
Год издания извлекается из текста записи автоматически. Если года в записи нет, проверка возраста пропускается.
---
## 6. Таблицы
| ID | Уровень | Сообщение | Причина и решение |
|----|---------|-----------|-------------------|
| `table.merge_header` | error | `Маркер склеивания ^/> нельзя использовать в первой (заголовочной) строке таблицы` | Вписать нормальный заголовок столбца |
| `table.merge_col` | error | `Маркер «>» нельзя ставить в первом столбце (нет ячейки слева)` | Убрать маркер |
| `table.continuation` | warning | `Word сам не вставит «Продолжение Таблицы N» при переносе…` | Разметка ни при чём: запускать с `--table-continuation word` (нужен Word и `pywin32`) либо `caption` |
| `listing.continuation` | warning | `Длинный листинг: Word сам не вставит «Продолжение Листинга N»…` | То же для `--listing-continuation`. Длинным считается блок кода от 40 строк — можно вынести полный код в приложение |
Замечания о продолжении выдаются только при режимах `off` и `soft`.
---
## 7. Приложения
| ID | Уровень | Сообщение | Причина и решение |
|----|---------|-----------|-------------------|
| `appendix.letter` | error | `Буква «{X}» не используется для обозначения приложений` | Запрещены Ё, З, Й, О, Ч, Ь, Ы, Ъ. Допустимы А, Б, В, Г, Д, Е, Ж, И, К, Л, М, Н, П, Р, С, Т, У, Ф, Х, Ц, Ш, Щ, Э, Ю, Я |
| `appendix.toc` | warning | `При нескольких приложениях после «ПРИЛОЖЕНИЯ» нужен перечень (основной текст) с номерами и названиями` | Добавить строки вида `Приложение А — Название` сразу после `# *ПРИЛОЖЕНИЯ` |
---
## 8. Проверка вёрстки `--check-pages`
Отдельная эвристика на готовом DOCX: ищет страницы, у которых снизу пусто больше 40 % полосы, а раздел продолжается на следующей странице.
| Ситуация | Сообщение |
|----------|-----------|
| Нет `pywin32` или Word | `Проверка вёрстки пропущена: нужен пакет pywin32 (pip install pywin32) и Microsoft Word.` |
| Word не открылся | `Проверка вёрстки пропущена: не удалось открыть Word ({ошибка}).` |
| Замечаний нет | `Проверка вёрстки (Word): замечаний по полупустым страницам нет (эвристика; возможны пропуски).` |
| Замечания есть | `Проверка вёрстки (Word): найдено замечаний — {N} (все эвристические, могут быть ложными).` |
| Конкретная страница | `[heuristic] page.fill: на стр. {N} пустой низ ~{X}% полосы, а раздел «{название}» продолжается на следующей странице…` |
Ложные срабатывания нормальны: крупный рисунок, конец пункта, намеренный разрыв. Чем помочь на уровне разметки: флаг `+landscape` у широкой схемы, перенос крупного объекта в приложение, сокращение листинга.
---
## 9. Рекомендуемый цикл доводки
```bash
python -m md2gost report.md --check-only --type coursework # 1. посмотреть замечания
# 2. отдать текст замечаний и .md модели с промптом ai/prompts/review-fix.md
python -m md2gost report.md --check-only --type coursework # 3. проверить повторно
python -m md2gost report.md -o report.docx --type coursework --check --strict
python -m md2gost report.docx --check-pages # 4. проверить вёрстку
```
Что проверка **не** ловит: смысловые ошибки, фактические неточности, выдуманные источники, слабую логику разделов и «машинный» стиль изложения. Стиль лечится промптом `ai/prompts/voice-human.md`, факты — вычиткой.
ai/context/cli.md
-242
View File
@@ -1,242 +0,0 @@
# Запуск, профили и настройки md2gost
Справочник по CLI, типам документов, конфигурационным файлам и оформлению. Движок один: интерфейс собирает те же параметры, что и аргументы командной строки.
---
## 1. Основные команды
```bash
python -m md2gost # окно интерфейса
python -m md2gost report.md -o report.docx --type coursework --check
python -m md2gost report.md --check-only --type vkr --strict
python -m md2gost report.docx -o report.md # импорт Word → Markdown
python -m md2gost report.docx --check-pages # проверка вёрстки готового DOCX
python -m word2md report.docx -o report.md # то же импортом напрямую
python -m md2fodt report.md -o report.fodt # экспорт в формат LibreOffice
md2gost-gui # окно интерфейса, точка входа
```
Без имени файла или с ключом `--gui` открывается окно. Windows-сборка: `build-exe.bat` даёт `dist\md2gost.exe`, двойной клик открывает окно, аргументы работают так же.
---
## 2. Типы документов `--type`
| Тип | Назначение | Нумерация объектов | Источники | Стиль |
|-----|-----------|--------------------|-----------|-------|
| `practice` (по умолчанию) | отчёт по практике | по разделам: 1.1, 2.3 | 5–7, не старше 5 лет | МИРЭА |
| `coursework` | курсовая работа | по разделам | 5–7, не старше 5 лет | МИРЭА |
| `vkr` | выпускная квалификационная работа | по разделам | не менее 10 в каждом подразделе списка | МИРЭА |
| `APID_coursework` | курсовая «Архитектура приложений и данных» | по разделам | 7–20, не старше 5 лет | МИРЭА |
| `PIS_custom` | итоговый отчёт по практическим работам | сквозная: 1, 2, 3 | не требуются | ПИС |
Что меняет профиль:
| Свойство | МИРЭА-профили | `PIS_custom` |
|----------|---------------|--------------|
| H1 | 18 пт, ПРОПИСНЫЕ, слева (СОДЕРЖАНИЕ и СПИСОК — по центру) | 14 пт, ПРОПИСНЫЕ, по центру |
| H2 / H3 | 16 пт / 14 пт | 14 пт, по ширине, отступ 1,25 см |
| Введение и заключение | обязательны | не требуются |
| Список источников | обязателен | не требуется |
| Особая структура | у `vkr` — приложение «Графический материал»; у `APID_coursework` — фиксированные заголовки разделов | H1 вида «Практическая работа №N. …» |
Общее оформление обоих пресетов: Times New Roman 14, интервал 1,5, поля 30/10/20/20 мм, абзацный отступ 1,25 см, выравнивание по ширине, подпись рисунка под ним, надписи таблицы и листинга сверху.
---
## 3. Все ключи командной строки
### Ввод и вывод
| Ключ | По умолчанию | Смысл |
|------|--------------|-------|
| `filename` | — | путь к `.md` (сборка DOCX) или `.docx` (импорт в Markdown) |
| `-o`, `--output` | рядом с исходником | путь результата |
| `-t`, `--template` | встроенный `Template.docx` | свой шаблон DOCX |
| `--gui` | — | открыть окно, можно сразу с файлом |
| `--type` | `practice` | тип документа |
### Структура и разметка
| Ключ | По умолчанию | Смысл |
|------|--------------|-------|
| `--heading-numbering {auto,manual}` | `manual` | `manual` — цифры из markdown, автонумерация Word отключена; `auto` — нумерует Word, цифры из заголовков снимаются |
| `--toc {manual,native}` | `native` | `native` — поле Word TOC (обновить при открытии); `manual` — md2gost собирает содержание с номерами страниц |
| `--emdash-to-hyphen` | выкл. | заменить все «—» на «-» |
| `--hr-pagebreak` | выкл. | строки `---`, `***`, `___` дают разрыв страницы (иначе игнорируются) |
| `--page-start N` | сквозная нумерация | начальный номер страницы в колонтитуле тела |
### Титул, задание, метаданные
| Ключ | По умолчанию | Смысл |
|------|--------------|-------|
| `--title` | — | готовый DOCX титульного листа; **отключает автогенерацию** |
| `--auto-title` | выкл. | собрать титул из `info_conv.yaml` и блока ` ```title ` |
| `--assignment` | — | DOCX бланка задания |
| `--student`, `--group` | из `md2gost.user.json` | ФИО и группа для автотитула |
| `--doc-author-from {os,student,custom}` | `os` | источник автора в свойствах DOCX |
| `--doc-author`, `--doc-last-modified-by`, `--doc-title`, `--doc-subject`, `--doc-keywords`, `--doc-comments`, `--doc-category` | — | поля свойств DOCX; пустое `--doc-comments` убирает штамп md2gost |
### Проверка
| Ключ | Смысл |
|------|-------|
| `--check` | проверить ТЗ и напечатать отчёт |
| `--check-only` | только проверка, без сборки |
| `--strict` | код выхода 1 при ошибках, документ не собирается |
| `--check-pages` | эвристическая проверка полупустых страниц через Microsoft Word (нужны Windows, Word, `pywin32`) |
Полный каталог замечаний — в `checker.md`.
### Таблицы и листинги через границу страницы
| Ключ | По умолчанию | Значения |
|------|--------------|----------|
| `--table-continuation` | `word` | `word` — после сохранения Word COM режет по реальной пагинации и подписывает «Продолжение Таблицы N»; `off` и `soft` — одна таблица без автоподписи; `legacy` и `caption` — резать по оценке высоты (возможны артефакты) |
| `--listing-continuation` | `word` | те же значения для листингов |
| `--table-repeat-header` | выкл. | повторять шапку таблицы на каждом фрагменте после разрыва |
Режим `word` требует Windows, установленный Microsoft Word и пакет `pywin32`. Без Word — `--table-continuation off`.
### Диаграммы
| Ключ | По умолчанию | Смысл |
|------|--------------|-------|
| `--plantuml-jar` | вшитый, иначе `PLANTUML_JAR` | путь к `plantuml.jar` |
| `--kroki-url` | `KROKI_URL`, иначе `http://localhost:8000` | локальный Kroki |
| `--diagram-fallback {local,remote,off}` | `remote` | что делать при недоступности локального рендера: `remote` — обратиться к `kroki.io`; `local` — ошибка; `off` — не рисовать |
| `--diagram-format {png,svg}` | `png` | формат вставки; `svg` даёт вектор с PNG-запасным (Word 2016+) |
| `--diagram-scale` | `2` | масштаб растра PlantUML и локального Mermaid; размер на странице как при 1 |
| `--schemes` | рядом с приложением или с `.md` | путь к `md2gost.schemes.json` |
| `--install-chromium` | — | скачать headless Chromium для Mermaid и выйти |
### Прочее
| Ключ | По умолчанию | Смысл |
|------|--------------|-------|
| `--styles` | пресет типа | путь к `md2gost.styles.json` |
| `--syntax-highlighting` | выкл. | подсветка синтаксиса в листингах |
| `--debug` | выкл. | отладочные данные в документе |
---
## 4. Импорт Word → Markdown
```bash
python -m word2md report.docx -o report.md
```
| Ключ | Смысл |
|------|-------|
| `-o`, `--output` | путь к `.md`, по умолчанию рядом с DOCX |
| `--media-dir` | каталог картинок, по умолчанию `<имя>_media` |
| `--keep-toc-pages` | сохранить строки содержания Word (иначе остаётся только `[TOC]`) |
| `--pagebreaks` | писать `---` на разрывах страниц |
Что распознаётся: заголовки и спецразделы, содержание, подписи «Рисунок N — …» / «Таблица N» / «Листинг N» (включая склейку «Продолжение…»), таблицы с объединением в `^` и `>`, листинги, формулы OMML в `$$…$$`, библиография `[n]: …`, ссылки `[n]`, часть перекрёстных ссылок восстанавливается как `@Рисунок:fig1_1`.
Что теряется: исходники PlantUML и Mermaid (остаются только картинки), язык оградки листингов, осмысленные `id` меток, надписи и SmartArt, сноски, плавающие рисунки. Титул и бланк задания до первого заголовка пропускаются, колонтитулы не импортируются.
После импорта результат имеет смысл довести промптом `ai/prompts/from-word.md` и проверить `--check`.
---
## 5. Экспорт в FODT
```bash
python -m md2fodt report.md -o report.fodt
```
Ключ `--emdash-to-hyphen` работает так же. PDF через LaTeX — каталог `md2latex/`.
---
## 6. Конфигурационные файлы
| Файл | Где лежит | Назначение |
|------|-----------|------------|
| `md2gost.user.json` | рядом с приложением | ФИО, группа, блок `metadata` со свойствами DOCX |
| `md2gost.schemes.json` | рядом с приложением, рядом с `.md`, либо путь в `--schemes` | схемы диаграмм: `title`, `docs`, `ai-prompt`, `includes`, `prefix`, `postfix`, `theme` |
| `md2gost.styles.json` | рядом с `.md` или путь в `--styles` | оверлей оформления поверх пресета |
| `info_conv.yaml` | рядом с `.md` | институт, кафедра, дисциплина, преподаватель, должность |
| `.md2gost-cache/` | рядом с `.md` | кэш отрисованных диаграмм |
| `md2gost.include-cache.json`, `include-cache/` | рядом с приложением | кэш скачанных `.puml` |
Приоритет загрузки, где каждый следующий слой сильнее: встроенный шаблон → файл рядом с приложением → файл рядом с `.md` → явный путь в ключе.
### `info_conv.yaml`
```yaml
Институт: Институт информационных технологий (ИИТ)
Кафедра: Кафедра цифровой трансформации (ЦТ)
Дисциплина: Проектирование архитектуры цифровой организации
Преподаватель: Иванов Иван Иванович
Должность: старший преподаватель, кафедра ЦТ
```
Плоский список `ключ: значение` в UTF-8. Строки с `#` — комментарии. ФИО и группа студента из файла **не читаются**: они берутся из профиля или ключей `--student` / `--group`.
### Автотитул: условия срабатывания
1. Включён `--auto-title` (или галочка «Автотитул»).
2. Не задан готовый `--title`.
3. Есть `info_conv.yaml` рядом с `.md` **или** блок ` ```title ` в начале файла.
4. Известны ФИО и группа — иначе конвертация останавливается с подсказкой «Для генерации титула нужны ФИО и группа студента».
Номер работы и год берутся из блока ` ```title ` (`number`, `year`); значения из блока сильнее `info_conv.yaml`. По умолчанию номер `1`, год — текущий.
### `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 }
}
}
```
Допустимые имена стилей: `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`, `bold`, `italic`, `all_caps`, `underline`, `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`.
Неизвестный ключ или неизвестное имя стиля — ошибка запуска. Не настраивается через JSON: табуляция оглавления, отступы списков, оформление формул, цвет текста (всегда чёрный).
---
## 7. Переменные окружения
| Переменная | Назначение |
|------------|------------|
| `PLANTUML_JAR` | путь к `plantuml.jar` |
| `KROKI_URL` | адрес локального Kroki, по умолчанию `http://localhost:8000` |
| `PLAYWRIGHT_BROWSERS_PATH` | каталог Chromium для Mermaid |
| `WORKING_DIR` | родительский каталог кэша диаграмм |
---
## 8. Где что в окне
| Меню | Содержимое |
|------|------------|
| Основные | тип документа, выходной путь, нумерация заголовков, содержание, режимы продолжения таблиц и листингов, смещение страниц |
| Настройки → Файлы | шаблон, титульный лист, бланк задания, стили JSON |
| Настройки → Студент | ФИО и группа (спрашиваются при первом запуске) |
| Настройки → Метаданные | свойства DOCX |
| Настройки → Диаграммы | PlantUML, Graphviz для DFD, Chromium для Mermaid, Kroki, формат, сброс кэша |
| Шаблоны UML | редактор `md2gost.schemes.json` |
| Справка | инструкция, документация, схемы, промпт для ИИ |
Кнопка «Импорт DOCX→MD» и перетаскивание `.docx` запускают импорт; перетаскивание `.md` подставляет файл для сборки.
---
## 9. Установка
```bash
pip install -e .
pip install pywin32 # Windows: продолжение таблиц через Word COM
```
Нужен Python 3.10 или новее (для DFD — 3.11 и новее). Для PlantUML нужна Java; для Mermaid — Chrome, Edge или скачиваемый Chromium; для DFD — Graphviz. IDEF0 рисуется локально без внешних зависимостей.
ai/context/diagrams.md
-567
View File
@@ -1,567 +0,0 @@
# Диаграммы в md2gost — справочник нотаций
Конвертер сам отрисовывает исходники диаграмм и вставляет их как Рисунок. Экспортировать схему в PNG вручную не нужно и вредно: картинка не пересобирается при правке.
---
## 1. Общие правила
```markdown
Диаграмма прецедентов приведена на @Рисунок:uc_main.
%uc_main Диаграмма прецедентов
```
…и сразу после — fenced-блок с исходником.
| Элемент | Правило |
|---------|---------|
| Метка и подпись | строка `%id Подпись` **перед** блоком |
| Ссылка в тексте | `@Рисунок:id` в предложении **до** блока |
| `id` | латиница, цифры, `_`; начинается с буквы; без дефисов |
| `+listing` в подписи | дополнительно выводит исходник схемы как Листинг со своим номером |
| `+landscape` в подписи | размещает рисунок на альбомной странице |
Подпись не должна содержать самостоятельных слов `listing` и `landscape` — они будут вырезаны как флаги.
Внутри блоков диаграмм типографская автозамена **не** работает, поэтому двойные кавычки и дефисы в синтаксисе схем сохраняются как есть. Это единственные защищённые блоки: в блоках кода кавычки заменяются.
---
## 2. Таблица оградок
| Оградка | Тело | Движок |
|---------|------|--------|
| ` ```uml `, ` ```plantuml ` | полный PlantUML с `@startuml` … `@enduml` | PlantUML |
| ` ```uml-c4 `, ` ```c4 ` | макросы C4 Container, без обёртки | PlantUML + stdlib C4 |
| ` ```uml-c4context ` | макросы C4 System Context | PlantUML + stdlib C4 |
| ` ```uml-c4component ` | макросы C4 Component | PlantUML + stdlib C4 |
| ` ```usecase `, ` ```uml-usecase ` | `actor`, `usecase`, связи, без обёртки | PlantUML |
| ` ```archimate `, ` ```uml-archimate ` | макросы ArchiMate 3.2, без обёртки | PlantUML + stdlib ArchiMate |
| ` ```mermaid `, ` ```mmd ` | синтаксис Mermaid | локальный Mermaid или Kroki |
| ` ```idef0 `, ` ```uml-idef0 ` | DSL IDEF0 | локальный рендер (Pillow) |
| ` ```dfd `, ` ```uml-dfd `, ` ```data-flow-diagram `, ` ```yourdon ` | DSL потоков данных | Graphviz или Kroki |
Правило про обёртку: в ` ```uml ` пишешь `@startuml` … `@enduml` **обязательно**; в схемах (`c4`, `usecase`, `archimate` и любых из `md2gost.schemes.json`) — **никогда**, схема подставит обёртку и `!include` сама.
---
## 3. PlantUML: готовые каркасы
### Диаграмма прецедентов
~~~markdown
%uc_main Диаграмма прецедентов системы
```uml
@startuml
left to right direction
skinparam packageStyle rectangle
actor "Студент" as student
actor "Преподаватель" as teacher
actor "Администратор" as admin
rectangle "Портал заявок" {
usecase "Подать заявку" as UC1
usecase "Проверить статус" as UC2
usecase "Согласовать заявку" as UC3
usecase "Аутентифицироваться" as UC4
usecase "Управлять справочниками" as UC5
}
student --> UC1
student --> UC2
teacher --> UC3
admin --> UC5
UC1 ..> UC4 : <<include>>
UC3 ..> UC4 : <<include>>
@enduml
```
~~~
### Диаграмма классов
~~~markdown
%class_domain Диаграмма классов предметной области
```uml
@startuml
skinparam classAttributeIconSize 0
class Request {
- id: int
- createdAt: datetime
- status: Status
+ submit(): void
+ cancel(): void
}
class Client {
- id: int
- name: str
- inn: str
}
enum Status {
NEW
IN_PROGRESS
DONE
}
class RequestService {
+ create(client: Client): Request
+ close(request: Request): void
}
Client "1" *-- "0..*" Request
Request --> Status
RequestService ..> Request
@enduml
```
~~~
### Диаграмма последовательности
~~~markdown
%seq_submit Последовательность обработки заявки
```uml
@startuml
autonumber
actor Студент as s
participant "Веб-клиент" as web
participant "Сервис заявок" as api
database "PostgreSQL" as db
s -> web : заполняет форму
web -> api : POST /requests
api -> db : INSERT request
db --> api : id
api --> web : 201 Created
web --> s : номер заявки
@enduml
```
~~~
### Диаграмма деятельности
~~~markdown
%act_flow Алгоритм обработки заявки
```uml
@startuml
start
:Принять заявку;
if (Данные полные?) then (да)
:Зарегистрировать;
:Назначить исполнителя;
else (нет)
:Вернуть на доработку;
stop
endif
:Исполнить заявку;
:Уведомить клиента;
stop
@enduml
```
~~~
### Диаграмма состояний
~~~markdown
%state_req Состояния заявки
```uml
@startuml
[*] --> Новая
Новая --> ВРаботе : назначен исполнитель
ВРаботе --> Исполнена : работы завершены
ВРаботе --> Отклонена : отказ
Исполнена --> [*]
Отклонена --> [*]
@enduml
```
~~~
### ER-диаграмма
~~~markdown
%erd_main Логическая модель данных
```uml
@startuml
hide circle
skinparam linetype ortho
entity "Клиент" as client {
* id : bigint <<PK>>
--
* name : varchar(255)
inn : varchar(12)
}
entity "Заявка" as request {
* id : bigint <<PK>>
--
* client_id : bigint <<FK>>
* created_at : timestamp
* status : varchar(32)
}
entity "Позиция заявки" as item {
* id : bigint <<PK>>
--
* request_id : bigint <<FK>>
* product : varchar(255)
* qty : int
}
client ||--o{ request
request ||--o{ item
@enduml
```
~~~
### Диаграмма компонентов и развёртывания
~~~markdown
%deploy_prod Схема развёртывания
```uml
@startuml
node "Сервер приложений" {
component "API заявок" as api
component "Планировщик" as sched
}
node "Сервер БД" {
database "PostgreSQL" as db
}
node "Рабочее место" {
component "Браузер" as browser
}
browser --> api : HTTPS
api --> db : SQL
sched --> db : SQL
@enduml
```
~~~
---
## 4. C4
Три уровня — три оградки. В теле только макросы; обёртка и `!include` добавляются схемой.
### Уровень 1: контекст
~~~markdown
%c4ctx Диаграмма контекста системы
```uml-c4context
Person(student, "Студент", "Подаёт заявки и отслеживает статус")
Person(staff, "Сотрудник деканата", "Обрабатывает заявки")
System(portal, "Портал заявок", "Приём и обработка заявок студентов")
System_Ext(sso, "Корпоративный SSO", "Единая аутентификация")
System_Ext(mail, "Почтовый сервис", "Уведомления")
Rel(student, portal, "Подаёт заявку", "HTTPS")
Rel(staff, portal, "Обрабатывает заявки", "HTTPS")
Rel(portal, sso, "Аутентифицирует пользователей", "OIDC")
Rel(portal, mail, "Отправляет уведомления", "SMTP")
```
~~~
### Уровень 2: контейнеры
~~~markdown
%c4cont Диаграмма контейнеров +landscape
```uml-c4
Person(student, "Студент", "Подаёт заявки")
System_Boundary(portal, "Портал заявок") {
Container(spa, "Веб-приложение", "React", "Интерфейс пользователя")
Container(api, "Сервис заявок", "FastAPI", "Бизнес-логика и валидация")
Container(worker, "Обработчик очереди", "Python", "Асинхронные задачи")
ContainerDb(db, "Основная БД", "PostgreSQL", "Заявки, клиенты, история")
ContainerDb(queue, "Очередь", "RabbitMQ", "Задачи на обработку")
}
System_Ext(sso, "Корпоративный SSO", "Аутентификация")
Rel(student, spa, "Работает с заявками", "HTTPS")
Rel(spa, api, "Вызывает методы", "REST/JSON")
Rel(api, db, "Читает и пишет", "SQL")
Rel(api, queue, "Публикует задачи", "AMQP")
Rel(worker, queue, "Читает задачи", "AMQP")
Rel(worker, db, "Обновляет статусы", "SQL")
Rel(spa, sso, "Аутентифицируется", "OIDC")
```
~~~
### Уровень 3: компоненты
~~~markdown
%c4comp Компоненты сервиса заявок
```uml-c4component
Container_Boundary(api, "Сервис заявок") {
Component(ctrl, "Контроллер заявок", "FastAPI Router", "Обработка HTTP-запросов")
Component(svc, "Служба заявок", "Python", "Правила обработки и переходы статусов")
Component(repo, "Репозиторий заявок", "SQLAlchemy", "Доступ к данным")
Component(auth, "Модуль авторизации", "Python", "Проверка прав по роли")
}
ContainerDb(db, "Основная БД", "PostgreSQL", "Заявки и клиенты")
Rel(ctrl, auth, "Проверяет права")
Rel(ctrl, svc, "Вызывает")
Rel(svc, repo, "Читает и пишет")
Rel(repo, db, "SQL-запросы")
```
~~~
### Основные макросы C4
| Макрос | Назначение |
|--------|------------|
| `Person(alias, "Имя", "Описание")` | пользователь-человек |
| `Person_Ext(...)` | внешний пользователь |
| `System(alias, "Имя", "Описание")` | система целиком |
| `System_Ext(...)` | внешняя система |
| `System_Boundary(alias, "Имя") { … }` | граница системы |
| `Container(alias, "Имя", "Технология", "Описание")` | контейнер |
| `ContainerDb(...)`, `ContainerQueue(...)` | база данных, очередь |
| `Container_Boundary(alias, "Имя") { … }` | граница контейнера |
| `Component(alias, "Имя", "Технология", "Описание")` | компонент |
| `Rel(from, to, "Действие", "Технология")` | связь |
| `Rel_U/D/L/R(...)` | связь с направлением раскладки |
| `LAYOUT_WITH_LEGEND()`, `LAYOUT_TOP_DOWN()`, `LAYOUT_LEFT_RIGHT()` | раскладка |
Правила качества: описания на русском, технологии — как принято (`PostgreSQL`, `React`); один уровень абстракции на диаграмму; 6–15 элементов; связи подписаны действием, а не «использует».
---
## 5. Mermaid
Идёт через локальный рендер (системный Chrome/Edge, Playwright Chromium или QuickJS) либо через Kroki.
~~~markdown
%mmd_flow Схема процесса согласования
```mermaid
flowchart TD
A[Заявка поступила] --> B{Данные полные?}
B -- да --> C[Регистрация]
B -- нет --> D[Возврат на доработку]
C --> E[Назначение исполнителя]
E --> F[Исполнение]
F --> G[Уведомление клиента]
D --> A
```
~~~
Поддерживаются `flowchart`, `sequenceDiagram`, `classDiagram`, `stateDiagram-v2`, `erDiagram`, `gantt`, `journey`, `pie`. Для отчёта по ГОСТ надёжнее PlantUML: Mermaid требует браузера или сети.
---
## 6. IDEF0 (FIPS 183)
Оградка ` ```idef0 `. Тело — не XML и не PlantUML, а собственный DSL. Рендер локальный, Java и сеть не нужны.
### Шапка формы
| Ключ | Значение |
|------|----------|
| `title` | название диаграммы |
| `node` | узел: `A-0`, `A0`, `A1` |
| `number` | номер листа |
| `author`, `project`, `date`, `rev` | поля NIST-формы |
| `status` | `WORKING`, `DRAFT`, `RECOMMENDED`, `PUBLICATION` |
| `context` | `TOP` для контекстной A-0, иначе родительский узел |
| `purpose`, `viewpoint` | цель и точка зрения модели |
| `used_at`, `reader`, `reader_date`, `notes`, `page` | необязательные поля формы |
| `form` | `kit` (по умолчанию, с рамкой) или `plain` |
### Боксы и стрелки
| Запись | Смысл |
|--------|-------|
| `[A0] Имя функции` или `box A0 Имя` | бокс функции |
| `<- Название` или `in` | вход (слева) |
| `^ Название` или `control` | управление (сверху) |
| `-> Название` или `out` | выход (справа) |
| `v Название` или `mech` | механизм (снизу) |
| `A1 <- Заявка [I1]` | явное указание бокса и код ICOM |
| `A1 -> A2 : план закупок` | внутренняя связь между боксами |
| `A1 -> A2.C : график` | связь в конкретный порт (`.I`, `.C`, `.O`, `.M`) |
| `A1, A2, A3 ^ Регламент [C1]` | одна стрелка в несколько боксов |
| `(in Секрет` | туннель на границе листа |
| `in) Локальный` | туннель у бокса |
| `call ИмяМодели` | вызов другой модели |
Стрелки без явного бокса относятся к последнему объявленному боксу.
### Контекстная диаграмма A-0
~~~markdown
%idef_a0 Контекстная диаграмма A-0
```idef0
title Распорядиться товаром
node A-0
number 1
author Иванов И. И.
project Модель торгового предприятия
date 08.02.2026
status PUBLICATION
context TOP
[A0] Распорядиться товаром
<- Спрос
^ Нормативная документация
-> Товар
v Персонал
```
~~~
### Декомпозиция A0
~~~markdown
%idef_a0d Декомпозиция A0
```idef0
title Распорядиться товаром
node A0
number 2
author Иванов И. И.
project Модель торгового предприятия
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]
```
~~~
Правила нотации: контекстная диаграмма — ровно один бокс; в декомпозиции 3–6 боксов «лесенкой» слева-сверху вниз-вправо; подписи стрелок — существительные; управление приходит сверху, механизм снизу.
---
## 7. DFD (диаграммы потоков данных)
Оградка ` ```dfd `. Синтаксис пакета `data-flow-diagram`. Рендер через Graphviz (вшитый, из `PATH` или скачанный) либо Kroki.
### Узлы и потоки
| Ключевое слово | Смысл |
|----------------|-------|
| `process Имя Подпись` | процесс |
| `entity Имя Подпись` | внешняя сущность |
| `store Имя Подпись` | хранилище данных |
| `control Имя Подпись` | элемент управления |
| `channel Имя Подпись` | канал |
| `style context` | оформление контекстной диаграммы |
| Поток | Смысл |
|-------|-------|
| `A --> B подпись` | поток данных |
| `A ->> B подпись` | двойной поток |
| `A <-> B подпись` | двунаправленный |
| `A ::> B подпись` | сигнал |
### Контекстная диаграмма
~~~markdown
%dfd_ctx Контекстная диаграмма потоков данных
```dfd
style context
entity Client Клиент
entity Warehouse Склад
process System Система учёта заявок
Client --> System заявка
System --> Client статус заявки
System --> Warehouse накладная
```
~~~
### Диаграмма нулевого уровня
~~~markdown
%dfd_l0 Диаграмма потоков данных нулевого уровня
```dfd
entity Client Клиент
entity Warehouse Склад
process Accept Принять заявку
process Register Зарегистрировать заявку
process Ship Сформировать накладную
store Orders Заявки
store Log Журнал операций
Client --> Accept заявка
Accept --> Orders новая заявка
Orders --> Register данные заявки
Register --> Log запись об изменении
Register --> Ship подтверждённая заявка
Ship --> Warehouse накладная
Ship --> Client уведомление
```
~~~
Правила нотации: на контекстной диаграмме один процесс; хранилища не соединяются напрямую с внешними сущностями; каждый процесс имеет и вход, и выход.
---
## 8. Что нужно для отрисовки
| Нотация | Требования | Запасной вариант |
|---------|------------|------------------|
| PlantUML, C4, ArchiMate, Use Case | Java и `plantuml.jar` (вшит в exe-сборку) | локальный Kroki, затем `kroki.io` при `--diagram-fallback remote` |
| Mermaid | системный Chrome или Edge; либо скачанный Chromium; либо QuickJS | Kroki |
| IDEF0 | ничего, локальный рендер | не требуется |
| DFD | Graphviz (вшитый, из `PATH` или кнопка «Скачать Graphviz») | Kroki |
Ключи: `--plantuml-jar`, `--kroki-url`, `--diagram-fallback local|remote|off`, `--diagram-format png|svg`, `--diagram-scale N` (по умолчанию 2 — качество растра).
Кэш готовых картинок — каталог `.md2gost-cache` рядом с `.md`; при правке исходника схемы картинка пересобирается автоматически.
---
## 9. Свои схемы
Файл `md2gost.schemes.json` (рядом с приложением, рядом с `.md` или путь в `--schemes`) задаёт новые оградки:
```json
{
"bpmn_like": {
"title": "Процессная схема",
"docs": "Шпаргалка макросов для подсказки в интерфейсе",
"ai-prompt": "Фрагмент, который дописывается в промпт для ИИ",
"includes": ["https://example.org/macros.puml"],
"prefix": "@startuml\n",
"postfix": "\n@enduml",
"theme": ""
}
}
```
`id` схемы: строчная латиница, цифры, `_`, начинается с буквы. После добавления доступны оградки ` ```bpmn_like ` и ` ```uml-bpmn_like `; в теле пишутся только макросы.
Слои загрузки, где каждый следующий сильнее: встроенный шаблон → файл рядом с приложением → файл рядом с `.md` → `--schemes`.
ai/context/syntax.md
-459
View File
@@ -1,459 +0,0 @@
# Диалект Markdown md2gost — полная спецификация
Справочник синтаксиса конвертера md2gost (Markdown → DOCX по ГОСТ 7.32-2017 и ТЗ РТУ МИРЭА). Всё, что здесь описано, извлечено из кода парсера, нумератора и проверки, а не из пользовательских инструкций.
Базовый парсер — Marko с расширением GFM. Всё, что не перечислено ниже как расширение, работает как обычный GitHub Flavored Markdown.
---
## 1. Расширения относительно обычного Markdown
| Конструкция | Смысл |
|-------------|-------|
| `# *ЗАГОЛОВОК` | раздел без автоматической нумерации |
| `[TOC]` | точка сборки содержания |
| `%id Подпись` | метка и подпись следующего объекта |
| `![alt](path "%id Подпись")` | метка и подпись рисунка-файла |
| `@Тип:id` | перекрёстная ссылка с автоподстановкой номера |
| `[1]: описание` | запись списка источников |
| `[1]`, `[2, 3]`, `[2, c. 21-25]` | ссылка на источник в тексте |
| `^` / `>` в ячейке таблицы | объединение ячеек |
| ` ```uml `, ` ```mermaid `, ` ```idef0 `, ` ```dfd `, ` ```uml-<схема>` | диаграмма, отрисовываемая конвертером |
| ` ```title ` | данные для автогенерации титульного листа |
| `+listing`, `+landscape` в строке `%` | флаги оформления объекта |
---
## 2. Заголовки
Синтаксис: от нуля до трёх ведущих пробелов, затем `#`…`######`, пробел, текст.
Регулярное выражение парсера: `^ {0,3}(#{1,6})((?=\s)[^\n]*?|[^\n\S]*)(?:(?<=\s)(?<!\\)#+)?[^\n\S]*$`
**Звёздочка** первым непробельным символом текста заголовка делает раздел ненумерованным и удаляется из видимого текста:
```markdown
# *ВВЕДЕНИЕ → раздел без номера
# 1 Анализ → нумерованный раздел
```
Пробел после `#` обязателен для корректной работы проверки (`^(#{1,6})\s+(\*?)(.+)$`).
### Спецразделы
Распознаются по тексту заголовка, приведённому к прописным. Список из кода проверки:
`СОДЕРЖАНИЕ`, `ВВЕДЕНИЕ`, `ЗАКЛЮЧЕНИЕ`, `СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ`, `СПИСОК ИСПОЛЬЗУЕМЫХ ИСТОЧНИКОВ`, `ПРИЛОЖЕНИЕ`, `ПРИЛОЖЕНИЯ`, а также любой заголовок, начинающийся на `ПРИЛОЖЕН`.
Для H1 из этого набора звёздочка обязательна — иначе ошибка `heading.numbered_special`.
Оформление в DOCX:
| Заголовок H1 | Выравнивание |
|--------------|--------------|
| `СОДЕРЖАНИЕ`, `СПИСОК ИСПОЛЬЗОВАННЫХ/ИСПОЛЬЗУЕМЫХ ИСТОЧНИКОВ` | по центру |
| `ВВЕДЕНИЕ`, `ЗАКЛЮЧЕНИЕ`, `ПРИЛОЖЕНИЯ`, нумерованные разделы | слева с абзацным отступом |
`СОДЕРЖАНИЕ` исключается из собираемого оглавления.
### Нумерация заголовков
| Режим CLI | Поведение |
|-----------|-----------|
| `--heading-numbering manual` (по умолчанию) | цифры остаются из markdown: `# 1 …`, `## 1.1 …`; автонумерация Word отключена |
| `--heading-numbering auto` | ведущие цифры (`^\d+(?:\.\d+)*\.?\s+`) снимаются с текста заголовка, номера ставит многоуровневый список Word |
При `manual` номера пиши сам. При `auto` их можно не писать — но безопаснее всегда писать и запускать конвертер в `manual`.
### `[TOC]`
Блочный элемент, шаблон `\[(TOC)\]+`. **Только прописными** — `[toc]` не распарсится (хотя проверка его увидит и замечания не выдаст). Ставится отдельной строкой, обычно сразу под `# *СОДЕРЖАНИЕ`.
Режимы сборки: `--toc native` (по умолчанию, поле Word, обновляется при открытии документа) и `--toc manual` (md2gost сам считает страницы).
---
## 3. Метки объектов: строка `%`
Шаблон: `\%(\w+)( (.+))?` — блочный элемент, прерывает открытый абзац.
- `id` = `\w+`: буквы, цифры, `_`. **Дефис, точка, пробел внутри `id` недопустимы.** Практическое правило: `[A-Za-z][A-Za-z0-9_]*`.
- Подпись необязательна: `%eq1` — валидная строка.
- Метка применяется к **следующему непустому блоку**. Пустые строки между меткой и объектом допустимы.
- Если подряд идут две метки, к объекту привяжется вторая.
- `%` в середине абзаца — обычный текст, не метка.
### Флаги в строке подписи
Шаблоны: `(?i)(?:^|\s)\+?listing\b` и `(?i)(?:^|\s)\+?landscape\b`.
| Флаг | Действие |
|------|----------|
| `+listing` | у диаграммы дополнительно выводится Листинг с её исходником (получает свой номер) |
| `+landscape` | объект размещается на альбомной странице |
Важные следствия из регулярных выражений:
1. Плюс необязателен: `listing` без плюса тоже сработает как флаг.
2. Регистр не важен: `+Landscape` = `+landscape`.
3. Флаги вырезаются из текста подписи в любом месте строки. **Поэтому подпись не должна содержать самостоятельных слов `listing` и `landscape`** — они исчезнут из подписи, а объект получит нежелательное оформление.
### Метка рисунка-файла
Метка задаётся в title изображения:
```markdown
![Архитектура системы](images/arch.png "%fig_arch Архитектура информационной системы")
```
Тот же шаблон `%(\w+)( (.+))?` и те же флаги.
### Куда попадает подпись
| Объект | Положение подписи в DOCX |
|--------|--------------------------|
| Рисунок и диаграмма | под объектом |
| Таблица | надпись над таблицей |
| Листинг | надпись над листингом |
| Формула | номер в скобках справа от формулы |
---
## 4. Перекрёстные ссылки `@Тип:id`
Шаблон: `@(\w+):(\w+)`. Пробелы вокруг двоеточия недопустимы. Знаки препинания после ссылки не съедаются, поэтому `@Рисунок:arch.` и `@Таблица:cmp,` работают корректно.
Принимаемые типы (регистр не важен при разрешении ссылки):
| Тип | Синонимы |
|-----|----------|
| `Рисунок` | `figure` |
| `Таблица` | `table` |
| `Листинг` | `listing` |
| `Формула` | `formula`, `equation` |
В документе ссылка разворачивается в «Тип Номер», например `Рисунок 1.1`. Неизвестная метка даёт в тексте `Рисунок?` — визуальный маркер ошибки; проверка сообщает `ref.dangling`.
Каноническая форма — русские названия: `@Рисунок:id`, `@Таблица:id`, `@Листинг:id`, `@Формула:id`.
### Соответствие меток и ссылок
Проверка сверяет два множества:
- метки — из `^%(\w+)` и из title картинок;
- ссылки — из `@[\wА-Яа-я]+:(\w+)`.
Метка без ссылки → предупреждение `ref.unused`. Ссылка без метки → ошибка `ref.dangling`. Правило простое: **сколько меток, столько и адресатов ссылок**.
---
## 5. Нумерация объектов
Области нумерации задаются профилем `--type`:
| Область | Профили | Вид номера |
|---------|---------|------------|
| `section` | `practice`, `coursework`, `vkr`, `APID_coursework` | `1.1`, `2.3`; в приложении — `Б.1` |
| `continuous` | `PIS_custom` | `1`, `2`, `3` на весь документ |
Счётчик раздела увеличивается только на **нумерованных H1** (то есть на `# 1 …`, а не на `# *ВВЕДЕНИЕ`).
Номер получают все объекты **кроме формул**: формуле номер присваивается, только если в исходном тексте есть `@Формула:id` (или `@Formula:id`) с её меткой. Формула без ссылки остаётся без номера.
Диаграмма с флагом `+listing` получает два номера под одной меткой: номер Рисунка и номер Листинга. Ссылки `@Рисунок:id` и `@Листинг:id` разрешатся каждая в свой номер.
---
## 6. Таблицы
Синтаксис GFM: строка заголовков, строка-разделитель, строки данных. Выравнивание через `:---`, `:---:`, `---:` поддерживается. Экранированный `\|` не считается границей столбца.
### Объединение ячеек
| Маркер | Смысл |
|--------|-------|
| `^` или `^^` | ячейка — продолжение ячейки **сверху** (rowspan) |
| `>` или `>>` | ячейка — продолжение ячейки **слева** (colspan) |
Маркер должен быть **единственным** содержимым ячейки после обрезки пробелов. Ограничения проверки: маркеры запрещены в строке заголовков (`table.merge_header`), `>` запрещён в первом столбце (`table.merge_col`).
```markdown
%tab_req Требования к системе
| Категория | Требование |
|-----------|------------|
| Производительность | обработка 1000 заявок в час |
| ^ | время отклика не более 2 с |
| Надёжность | доступность 99,5 % |
```
### Правила ТЗ
- Графа «№ п/п» запрещена (`table.nopp`, шаблон `№\s*п\s*/\s*п`).
- Таблицу из одной строки данных не оформляют таблицей.
- Таблицы и рисунки не размещают внутри списков.
### Продолжение на следующей странице
DOCX не умеет сам подписывать «Продолжение Таблицы N». Режимы `--table-continuation` и `--listing-continuation`: `word` (по умолчанию; после сохранения Word COM режет по реальной пагинации), `off`, `soft`, `legacy`, `caption`. Режим `word` требует Windows, Microsoft Word и пакет `pywin32`.
---
## 7. Листинги
Любой fenced-блок с языком, который **не** является языком диаграммы, становится Листингом.
~~~markdown
%code_volume Процедура расчёта объёма
```python
def volume(count: int, size: float) -> float:
return count * size
```
~~~
Подсветка синтаксиса включается ключом `--syntax-highlighting` (по умолчанию выключена).
### Ловушка: автозамена внутри кода
Препроцессор применяет типографские правки ко всему тексту, **исключая только блоки диаграмм**. Блоки кода не защищены:
| В исходнике | В DOCX |
|-------------|--------|
| `print("hello")` | `print(«hello»)` |
| `x = a - b` | `x = a — b` |
Обход: одинарные кавычки в примерах кода и вычитание без пробелов (`a-b`). Ключ `--emdash-to-hyphen` меняет направление замены тире, но кавычки правит всегда.
---
## 8. Формулы
| Форма | Шаблон | Назначение |
|-------|--------|------------|
| Выключная | `\$\$([\S\s]*?)\$\$` | отдельный блок, нумеруемая формула |
| Инлайновая | `\$(.*?)\$` | обозначения в тексте: `$N$` |
```markdown
%eq_volume
$$
V = N \times S
$$
где $N$ — число записей; $S$ — средний размер записи, байт.
Оценка по (@Формула:eq_volume) используется при выборе хранилища.
```
Номер присваивается только при наличии ссылки. Расшифровка обозначений начинается со слова «где» без двоеточия.
---
## 9. Диаграммы
Fenced-блок с языком диаграммы превращается в Рисунок; исходник отрисовывается конвертером.
### Встроенные языки
| Оградка | Движок |
|---------|--------|
| `uml`, `plantuml` | PlantUML (java + `plantuml.jar`, иначе Kroki) |
| `mermaid`, `mmd` | локальный Mermaid (браузер / QuickJS), иначе Kroki |
| `idef0`, `uml-idef0` | локальный рендер на Pillow, без Java и сети |
| `dfd`, `uml-dfd`, `data-flow-diagram`, `yourdon`, `uml-yourdon` | пакет `data-flow-diagram` + Graphviz, иначе Kroki |
### Схемы из `md2gost.schemes.json`
Оградка `uml-<id>` или просто `<id>`, где `<id>` — идентификатор схемы (`^[a-z][a-z0-9_]*$`). Встроенные схемы:
| id | Что это | Оградка |
|----|---------|---------|
| `c4` | C4 Container | ` ```uml-c4 ` / ` ```c4 ` |
| `c4context` | C4 System Context | ` ```uml-c4context ` |
| `c4component` | C4 Component | ` ```uml-c4component ` |
| `usecase` | UML Use Case | ` ```uml-usecase ` / ` ```usecase ` |
| `archimate` | ArchiMate 3.2 | ` ```uml-archimate ` / ` ```archimate ` |
В теле схемы пишутся **только макросы**: обёртку `@startuml` … `@enduml` и `!include` подставляет схема. В блоке ` ```uml ` наоборот — `@startuml` … `@enduml` обязательны.
Неизвестный `uml-<id>` даёт ошибку рендера: `Схема диаграммы «<id>» не найдена`.
Подробный синтаксис всех нотаций — в `diagrams.md`, ArchiMate — в `archimate.md`.
---
## 10. Источники
### Запись списка
Шаблон строки: `^\[(\d+(?:\.\d+)?)\]:\s*(.+)$`
Записи размещаются под заголовком, совпадающим с `^#\s*\*?\s*СПИСОК\s+ИСПОЛЬЗОВАНН?ЫХ\s+ИСТОЧНИКОВ\s*$` — то есть «СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ» или «СПИСОК ИСПОЛЬЗУЕМЫХ ИСТОЧНИКОВ».
```markdown
# *СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ
[1]: Иванов И. И. Проектирование информационных систем: учебник. — М.: Инфра-М, 2023. — 320 с.
[2]: ГОСТ 7.32-2017. Отчёт о научно-исследовательской работе. — М.: Стандартинформ, 2018. — 32 с.
```
Препроцессор сам расставит пустые строки между записями, но безопаснее писать их сразу.
Для ВКР список делится подразделами `##`; ключ записи получает вид `[1.5]` — номер раздела и номер внутри раздела.
### Ссылка в тексте
Шаблон: `\[(\d+(?:\.\d+)?(?:\s*,\s*\d+(?:\.\d+)?)*)(?:\s*,\s*[cс]\.\s*[\d\-–]+)?\]`
| Форма | Пример |
|-------|--------|
| одиночная | `[1]`, `[1.5]` |
| перечисление | `[2, 3]`, `[2,3]` |
| с указанием страниц | `[2, c. 21-25]`, `[2.18, с. 21–25]` — буква `c` латинская или русская |
В DOCX номер становится внутренней гиперссылкой на запись списка.
Сноски `[^1]` запрещены (`footnote`).
---
## 11. Приложения
```markdown
# *ПРИЛОЖЕНИЯ
Приложение А — Листинг модуля обработки заявок
Приложение Б — Схема базы данных
## Приложение А Листинг модуля обработки заявок
## Приложение Б Схема базы данных
```
- Заголовок приложения распознаётся шаблоном `^ПРИЛОЖЕНИЕ\s+([А-ЯA-ZЁ])(?:\s+(.+))?$` без учёта регистра. Оформляется как Heading 3 по центру с разрывом страницы; название — отдельной строкой под ним.
- Допустимые буквы: `АБВГДЕЖИКЛМНПРСТУФХЦШЩЭЮЯ`. Запрещённые: `Ё З Й О Ч Ь Ы Ъ` (ошибка `appendix.letter`).
- Если букву не указать или указать запрещённую, конвертер подставит следующую допустимую по порядку.
- При двух и более приложениях после `# *ПРИЛОЖЕНИЯ` нужен перечень обычным текстом, иначе предупреждение `appendix.toc`. Если перечня нет, конвертер вставит его сам, но лучше писать явно.
- Объекты внутри приложения нумеруются с буквой приложения: `Рисунок Б.1`.
---
## 12. Блок ` ```title `
Первый блок с оградкой `title` в файле вырезается до разбора markdown и используется для автогенерации титульного листа (только при `--auto-title`).
````markdown
```title
number: 1
year: 2026
```
# *СОДЕРЖАНИЕ
[TOC]
````
Тело — плоские строки `ключ: значение`. Принимаемые ключи:
| Поле | Ключи |
|------|-------|
| Институт | `institute`, `институт`, `инститиут` |
| Кафедра | `department`, `кафедра` |
| Дисциплина | `discipline`, `дисциплина` |
| Преподаватель | `teacher`, `преподаватель`, `преподователь` |
| Должность преподавателя | `teacher_position`, `должность`, `должность преподавателя` |
| Номер работы | `number`, `номер`, `№`, `n` — по умолчанию `1` |
| Год | `year`, `год` — по умолчанию текущий |
ФИО и группа студента **из блока не читаются**: они берутся из профиля приложения или ключей `--student` / `--group`.
Остальные академические поля можно держать в файле `info_conv.yaml` рядом с `.md`; значения из блока ` ```title ` сильнее.
---
## 13. Автоматические правки текста
Препроцессор применяет ко всему тексту, **кроме блоков диаграмм**:
| Правило | Было | Стало |
|---------|------|-------|
| Русские кавычки | `"текст"` | `«текст»` |
| Тире вместо дефиса между словами | `слово - слово` | `слово — слово` |
| Разделение записей списка источников | склеенные строки `[n]:` | каждая записью-абзацем |
Кавычки не заменяются, если содержимое начинается с `%` (защита строк подписей).
Ключ `--emdash-to-hyphen` включает обратную замену: все `—` становятся `-`.
---
## 14. Прочее
| Конструкция | Поведение |
|-------------|-----------|
| `---`, `***`, `___` | по умолчанию **игнорируются**; с ключом `--hr-pagebreak` дают разрыв страницы |
| Обычные `**жирный**`, `*курсив*`, `` `код` ``, ссылки, списки | работают как в GFM |
| HTML-блоки | не поддерживаются, вставляются как предупреждение в документ |
| Комментарии | синтаксиса комментариев нет |
| Заголовок глубже `###` | парсится, но в оформлении ТЗ не предусмотрен |
| Дефис в обычном тексте | превращается в неразрывный дефис |
---
## 15. Полный минимальный пример
~~~markdown
# *СОДЕРЖАНИЕ
[TOC]
# *ВВЕДЕНИЕ
Цель работы — спроектировать модуль учёта заявок.
# 1 Анализ предметной области
Обобщённая архитектура приведена на @Рисунок:fig_arch.
![Архитектура](images/arch.png "%fig_arch Архитектура информационной системы")
Сравнение подходов сведено в @Таблица:tab_cmp.
%tab_cmp Сравнение подходов к реализации
| Подход | Трудоёмкость | Гибкость |
|--------|--------------|----------|
| Монолит | низкая | низкая |
| Микросервисы | высокая | высокая |
Модульная структура описана в источнике [1].
# 2 Проектирование
Оценка объёма данных выполняется по (@Формула:eq_volume).
%eq_volume
$$
V = N \times S
$$
где $N$ — число записей; $S$ — средний размер записи, байт.
Реализация приведена в @Листинг:code_volume.
%code_volume Процедура расчёта объёма
```python
def volume(count: int, size: float) -> float:
return count * size
```
# *ЗАКЛЮЧЕНИЕ
Спроектирован модуль учёта заявок, оценён объём хранилища.
# *СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ
[1]: Иванов И. И. Проектирование информационных систем: учебник. — М.: Инфра-М, 2023. — 320 с.
~~~
ai/examples/coursework.md
-281
View File
@@ -1,281 +0,0 @@
# *СОДЕРЖАНИЕ
[TOC]
# *ВВЕДЕНИЕ
Обслуживание парка оборудования в производственных подразделениях опирается на заявки, которые до сих пор часто передаются по телефону и фиксируются в электронных таблицах. При таком порядке теряется история обращений, а срок реакции зависит от загруженности диспетчера.
Объектом работы является процесс приёма и исполнения заявок на техническое обслуживание. Предмет работы — архитектура и программная реализация модуля учёта таких заявок.
Цель работы — спроектировать и реализовать модуль учёта заявок, обеспечивающий регистрацию обращений, контроль сроков исполнения и хранение истории обслуживания.
Для достижения цели решаются следующие задачи:
1. Проанализировать процесс обработки заявок и существующие решения для его автоматизации.
2. Сформировать требования к модулю и спроектировать его архитектуру и модель данных.
3. Реализовать ключевые функции модуля и оценить объём хранилища.
В работе применяются структурный анализ процессов, объектно-ориентированное моделирование в нотации UML и сравнительный анализ программных решений.
# 1 Анализ процесса обработки заявок
## 1.1 Описание процесса и его участников
В обработке заявки участвуют три роли: инициатор со стороны производственного подразделения, диспетчер службы обслуживания и исполнитель. Инициатор сообщает о неисправности, диспетчер регистрирует обращение и назначает исполнителя, исполнитель выполняет работы и закрывает заявку.
Границы автоматизируемого процесса и его внешние интерфейсы приведены на @Рисунок:idef_a0.
%idef_a0 Контекстная диаграмма процесса обслуживания
```idef0
title Обработать заявку на обслуживание
node A-0
number 1
project Модуль учёта заявок
context TOP
[A0] Обработать заявку на обслуживание
<- Обращение инициатора
^ Регламент технического обслуживания
-> Закрытая заявка с отметкой о работах
v Служба обслуживания
```
Наблюдение за работой диспетчера в течение недели дало следующие показатели: в среднем 42 обращения в сутки, среднее время регистрации 6 минут, доля обращений с неполными сведениями об оборудовании 18 %. Именно неполнота сведений вызывает повторное обращение к инициатору и удлиняет реакцию на заявку.
## 1.2 Сравнение существующих решений
Для автоматизации процесса рассматривались три варианта: универсальная система управления обслуживанием, модуль в составе используемой на предприятии учётной системы и собственная разработка. Критериями сравнения выбраны стоимость владения, возможность интеграции со справочником оборудования и трудоёмкость внедрения [1].
Результаты сравнения сведены в @Таблица:tab_cmp.
%tab_cmp Сравнение вариантов автоматизации процесса
| Вариант | Стоимость владения | Интеграция со справочником | Трудоёмкость внедрения |
|---------|--------------------|----------------------------|------------------------|
| Универсальная система обслуживания | высокая | через файловый обмен | средняя |
| Модуль учётной системы | средняя | штатная | высокая |
| Собственная разработка | низкая | по REST | низкая |
Универсальная система покрывает больше сценариев, чем требуется подразделению, и вносит внешний файловый обмен, который сам становится источником расхождений [2]. Модуль учётной системы обеспечивает штатную интеграцию, но его доработка требует привлечения поставщика. Собственная разработка выбрана как вариант, закрывающий требования при наименьшей трудоёмкости.
## 1.3 Требования к модулю
Требования сгруппированы по категориям и приведены в @Таблица:tab_req. Формулировки нефункциональных требований опираются на рекомендации по описанию качества программных систем [3].
%tab_req Требования к модулю учёта заявок
| Категория | Требование |
|-----------|------------|
| Функциональные | регистрация заявки с привязкой к единице оборудования |
| ^ | назначение исполнителя и контроль срока |
| ^ | хранение истории обслуживания единицы оборудования |
| Производительность | обработка 100 заявок в час при 20 одновременных пользователях |
| ^ | время отклика интерфейса не более 2 с |
| Надёжность | доступность не ниже 99,5 % в рабочие часы |
| Интеграция | получение справочника оборудования по REST |
Ограничения проекта: развёртывание в контуре предприятия, единая аутентификация через корпоративную службу, хранение данных не менее трёх лет.
# 2 Проектирование модуля
## 2.1 Архитектура модуля
Модуль спроектирован по трёхуровневой схеме: клиентское приложение, сервис прикладной логики и хранилище. Такое разделение позволяет обновлять правила обработки заявок без изменения клиента [4].
Контейнерная структура модуля приведена на @Рисунок:c4_containers.
%c4_containers Контейнеры модуля учёта заявок +landscape
```uml-c4
Person(dispatcher, "Диспетчер", "Регистрирует и распределяет заявки")
Person(worker, "Исполнитель", "Выполняет работы по заявке")
System_Boundary(app, "Модуль учёта заявок") {
Container(spa, "Веб-клиент", "React", "Интерфейс диспетчера и исполнителя")
Container(api, "Сервис заявок", "FastAPI", "Правила обработки и контроль сроков")
ContainerDb(db, "Хранилище заявок", "PostgreSQL", "Заявки, работы, история")
}
System_Ext(equip, "Справочник оборудования", "Учётная система предприятия")
System_Ext(sso, "Корпоративная служба входа", "Единая аутентификация")
Rel(dispatcher, spa, "Регистрирует заявки", "HTTPS")
Rel(worker, spa, "Отмечает выполнение", "HTTPS")
Rel(spa, api, "Вызывает методы", "REST/JSON")
Rel(api, db, "Читает и пишет", "SQL")
Rel(api, equip, "Запрашивает единицы оборудования", "REST")
Rel(spa, sso, "Аутентифицирует пользователя", "OIDC")
```
Справочник оборудования остаётся во внешней учётной системе: дублирование его в модуле привело бы к расхождению данных при выводе оборудования из эксплуатации.
## 2.2 Модель данных
Логическая модель данных охватывает три сущности: заявку, работу по заявке и запись истории обслуживания. Единица оборудования в модуле не хранится, вместо неё сохраняется её идентификатор во внешнем справочнике.
Модель данных приведена на @Рисунок:erd.
%erd Логическая модель данных модуля
```uml
@startuml
hide circle
skinparam linetype ortho
entity "Заявка" as request {
* id : bigint <<PK>>
--
* equipment_ref : varchar(32)
* created_at : timestamp
* due_at : timestamp
* status : varchar(16)
description : text
}
entity "Работа" as work {
* id : bigint <<PK>>
--
* request_id : bigint <<FK>>
* performer : varchar(128)
* started_at : timestamp
finished_at : timestamp
}
entity "Запись истории" as history {
* id : bigint <<PK>>
--
* request_id : bigint <<FK>>
* changed_at : timestamp
* old_status : varchar(16)
* new_status : varchar(16)
}
request ||--o{ work
request ||--o{ history
@enduml
```
Статус заявки хранится строкой из фиксированного набора значений, а не ссылкой на справочник: набор состояний определяется регламентом обслуживания и меняется вместе с версией модуля.
## 2.3 Оценка объёма хранилища
Объём данных за период эксплуатации оценивается произведением числа записей на средний размер записи с учётом коэффициента служебных структур базы данных [5].
%eq_volume
$$
V = N \cdot S \cdot k
$$
где $N$ — число заявок за период; $S$ — средний размер записи вместе со связанными работами и историей, байт; $k$ — коэффициент накладных расходов хранилища.
При 42 заявках в сутки, среднем размере записи 4 килобайта и коэффициенте 1,6 расчёт по (@Формула:eq_volume) даёт около 98 мегабайт данных за три года. Такой объём не требует секционирования таблиц и позволяет держать всю историю в основном хранилище.
# 3 Реализация ключевых функций
## 3.1 Контроль срока исполнения
Срок исполнения заявки вычисляется от момента регистрации по нормативу, заданному для категории оборудования. Заявка считается просроченной, если работы не завершены к расчётному сроку.
Реализация проверки приведена в @Листинг:code_overdue.
%code_overdue Проверка просроченных заявок
```python
from datetime import datetime, timedelta
NORMS_HOURS = {'critical': 4, 'standard': 24, 'planned': 72}
def due_at(created_at: datetime, category: str) -> datetime:
return created_at + timedelta(hours=NORMS_HOURS[category])
def is_overdue(request: dict, now: datetime) -> bool:
if request['status'] == 'closed':
return False
return now > due_at(request['created_at'], request['category'])
```
Нормативы вынесены в отдельную структуру: их изменение регламентом не требует правки логики проверки.
## 3.2 Проверка полноты сведений при регистрации
Доля обращений с неполными сведениями об оборудовании составляла 18 %, поэтому регистрация заявки блокируется до получения идентификатора единицы оборудования из внешнего справочника. Обращение к справочнику выполняется при вводе, а не при сохранении: диспетчер видит ошибку до того, как заполнит остальные поля.
Проверка вернула долю отклонённых при вводе форм на уровне 4 % от общего числа регистраций, остальные обращения были дополнены сведениями сразу.
# *ЗАКЛЮЧЕНИЕ
Проанализирован процесс приёма и исполнения заявок на техническое обслуживание: в нём участвуют три роли, а основной потерей времени является уточнение сведений об оборудовании, затрагивающее почти каждое пятое обращение.
Сформированы требования к модулю и выбран вариант собственной разработки — он закрывает требования подразделения при наименьшей трудоёмкости внедрения и позволяет получать справочник оборудования по REST вместо файлового обмена.
Модуль спроектирован по трёхуровневой схеме; модель данных содержит заявку, работу и запись истории, а справочник оборудования остаётся во внешней системе. Оценка объёма хранилища за три года эксплуатации составила около 98 мегабайт, что не требует секционирования таблиц.
Реализованы контроль срока исполнения с нормативами по категориям оборудования и проверка полноты сведений на этапе ввода: доля неполных обращений снизилась с 18 % до 4 %.
# *СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ
[1]: Ричардс М., Форд Н. Фундаментальный подход к программной архитектуре: паттерны, свойства, проверенные методы. — СПб.: Питер, 2023. — 432 с.
[2]: Клеппман М. Высоконагруженные приложения: программирование, масштабирование, поддержка. — СПб.: Питер, 2022. — 640 с.
[3]: ГОСТ Р ИСО/МЭК 25010-2015. Информационные технологии. Системная и программная инженерия. Требования и оценка качества систем и программного обеспечения. — М.: Стандартинформ, 2022. — 36 с.
[4]: Ньюмен С. От монолита к микросервисам. — М.: ДМК Пресс, 2022. — 274 с.
[5]: Документация PostgreSQL 16. Раздел «Database Physical Storage». — URL: https://www.postgresql.org/docs/16/storage.html (дата обращения: 14.02.2026).
[6]: Кириллина Ю. В. и др. Методические указания по оформлению учебных работ. — М.: РТУ МИРЭА, 2022. — 64 с.
# *ПРИЛОЖЕНИЯ
Приложение А — Схема состояний заявки
Приложение Б — Фрагмент сценария регистрации заявки
## Приложение А Схема состояний заявки
Переходы между состояниями заявки приведены на @Рисунок:state_req. Требования к оформлению схемы приняты по методическим указаниям [6].
%state_req Состояния заявки на обслуживание
```uml
@startuml
[*] --> Новая
Новая --> Назначена : назначен исполнитель
Назначена --> ВРаботе : работы начаты
ВРаботе --> Закрыта : работы завершены
Назначена --> Отклонена : обращение неправомерно
Новая --> Отклонена : обращение неправомерно
Закрыта --> [*]
Отклонена --> [*]
@enduml
```
## Приложение Б Фрагмент сценария регистрации заявки
Последовательность обращений при регистрации заявки приведена на @Рисунок:seq_reg.
%seq_reg Последовательность регистрации заявки
```uml
@startuml
autonumber
actor Диспетчер as d
participant "Веб-клиент" as spa
participant "Сервис заявок" as api
participant "Справочник оборудования" as equip
database "Хранилище" as db
d -> spa : вводит идентификатор оборудования
spa -> api : GET /equipment/{ref}
api -> equip : GET /units/{ref}
equip --> api : сведения об оборудовании
api --> spa : карточка оборудования
d -> spa : заполняет описание неисправности
spa -> api : POST /requests
api -> db : INSERT request
db --> api : идентификатор заявки
api --> spa : номер заявки и срок исполнения
@enduml
```
ai/examples/pis-report.md
-224
View File
@@ -1,224 +0,0 @@
# *СОДЕРЖАНИЕ
[TOC]
# Практическая работа №1. Описание предметной области и границ системы
## Цель работы
Описать предметную область складского учёта, выделить участников процесса и зафиксировать границы автоматизируемой системы.
## Ход работы
Рассматривается склад готовой продукции среднего предприятия: три зоны комплектации, один участок приёмки, две смены по четыре кладовщика. Через склад проходит около 400 отгрузок в сутки, приёмка занимает от 20 до 90 минут на партию.
Участники процесса и их задачи приведены в @Таблица:pr1_roles.
%pr1_roles Участники процесса складского учёта
| Участник | Задача | Что получает на выходе |
|----------|--------|------------------------|
| Кладовщик приёмки | сверяет поступившую партию с накладной | акт приёмки |
| Комплектовщик | собирает заказ по заданию | укомплектованный заказ |
| Кладовщик отгрузки | оформляет передачу заказа перевозчику | подписанная накладная |
| Начальник склада | контролирует остатки и сроки | сводка по остаткам |
Границы системы и её внешнее окружение показаны на @Рисунок:pr1_ctx.
%pr1_ctx Контекстная диаграмма потоков данных
```dfd
style context
entity Supplier Поставщик
entity Carrier Перевозчик
entity Sales Отдел продаж
process System Система складского учёта
Supplier --> System товарная накладная
Sales --> System заказ на отгрузку
System --> Carrier накладная на отгрузку
System --> Sales сведения об остатках
```
Границы приняты по участку от приёмки партии до передачи заказа перевозчику. Бухгалтерский учёт и закупки остаются за пределами системы: они ведутся в учётной системе предприятия и получают из системы только сводки.
## Выводы
Основным ограничением процесса является ручной ввод накладных при приёмке: он даёт до 6 % расхождений в учёте остатков и удлиняет приёмку партии в среднем на 25 минут. Именно этот участок определяет требования к системе.
# Практическая работа №2. Модель бизнес-процессов склада
## Цель работы
Построить функциональную модель процесса складского учёта в нотации IDEF0 и определить состав функций верхнего уровня.
## Ход работы
Контекстная диаграмма процесса приведена на @Рисунок:pr2_a0.
%pr2_a0 Контекстная диаграмма A-0
```idef0
title Обеспечить движение товара на складе
node A-0
number 1
project Система складского учёта
context TOP
[A0] Обеспечить движение товара на складе
<- Товарная накладная
<- Заказ на отгрузку
^ Регламент складских операций
-> Подписанная накладная на отгрузку
-> Сводка по остаткам
v Персонал склада
```
Декомпозиция функции верхнего уровня выделила три функции, приведённые на @Рисунок:pr2_a0d.
%pr2_a0d Декомпозиция A0
```idef0
title Обеспечить движение товара на складе
node A0
number 2
project Система складского учёта
context A-0
purpose Сократить расхождения учёта при приёмке и отгрузке
viewpoint Начальник склада
[A1] Принять партию
[A2] Разместить и хранить
[A3] Скомплектовать и отгрузить
A1 <- Товарная накладная [I1]
A3 <- Заказ на отгрузку [I2]
A1, A2, A3 ^ Регламент складских операций [C1]
A2 ^ Схема зонирования склада [C2]
A1 -> A2 : принятая партия
A2 -> A3 : товар к комплектации
A3 -> Подписанная накладная на отгрузку [O1]
A2 -> Сводка по остаткам [O2]
A1, A2, A3 v Персонал склада [M1]
A2 v Складское оборудование [M2]
```
Схема зонирования вынесена в управление, а не во вход: она задаёт правила размещения и не расходуется в процессе.
## Выводы
Функция размещения оказалась единственной, которая одновременно получает управление от схемы зонирования и формирует сводку по остаткам. Расхождения учёта возникают именно на переходе от приёмки к размещению, когда партия физически принята, но ещё не отражена в остатках.
# Практическая работа №3. Модель данных системы
## Цель работы
Спроектировать логическую модель данных системы складского учёта и обосновать состав сущностей.
## Ход работы
Модель данных приведена на @Рисунок:pr3_erd.
%pr3_erd Логическая модель данных системы
```uml
@startuml
hide circle
skinparam linetype ortho
entity "Партия" as batch {
* id : bigint <<PK>>
--
* supplier : varchar(255)
* accepted_at : timestamp
* invoice_no : varchar(32)
}
entity "Товарная позиция" as item {
* id : bigint <<PK>>
--
* batch_id : bigint <<FK>>
* sku : varchar(32)
* qty : numeric(12,3)
zone : varchar(16)
}
entity "Заказ на отгрузку" as order_ {
* id : bigint <<PK>>
--
* created_at : timestamp
* status : varchar(16)
}
entity "Строка заказа" as line {
* id : bigint <<PK>>
--
* order_id : bigint <<FK>>
* sku : varchar(32)
* qty : numeric(12,3)
}
batch ||--o{ item
order_ ||--o{ line
@enduml
```
Остаток по артикулу не хранится отдельным полем, а вычисляется как разность принятого и отгруженного количества. Такое решение исключает расхождение между остатком и первичными документами, но требует индекса по артикулу для приемлемой скорости выборки.
Соответствие сущностей модели функциям процесса приведено в @Таблица:pr3_map.
%pr3_map Соответствие сущностей функциям процесса
| Функция | Сущности | Что изменяется |
|---------|----------|----------------|
| Принять партию | Партия, Товарная позиция | добавляются позиции с нулевой зоной |
| Разместить и хранить | Товарная позиция | заполняется зона размещения |
| Скомплектовать и отгрузить | Заказ на отгрузку, Строка заказа | создаются строки и уменьшается доступное количество |
## Выводы
Модель обходится четырьмя сущностями за счёт вычисляемого остатка. Слабое место решения — скорость расчёта остатка при росте числа позиций: при объёме свыше миллиона строк потребуется материализованное представление.
# Практическая работа №4. Расчёт нагрузки на систему
## Цель работы
Оценить пиковую нагрузку на систему складского учёта и объём хранилища на три года эксплуатации.
## Ход работы
Пиковая интенсивность запросов оценивается по числу операций в смену с учётом коэффициента неравномерности.
%pr4_eq_load
$$
\lambda_{\max} = \frac{Q \cdot m}{T} \cdot k
$$
где $Q$ — число отгрузок в смену; $m$ — среднее число запросов на одну отгрузку; $T$ — длительность смены в секундах; $k$ — коэффициент неравномерности нагрузки.
Расчёт по (@Формула:pr4_eq_load) при 200 отгрузках в смену, 14 запросах на отгрузку, смене 12 часов и коэффициенте 2,5 даёт пиковую интенсивность около 0,16 запроса в секунду.
Реализация расчёта приведена в @Листинг:pr4_code.
%pr4_code Расчёт пиковой интенсивности запросов
```python
def peak_rate(shipments: int, requests_per_shipment: int,
shift_seconds: int, unevenness: float) -> float:
return shipments * requests_per_shipment / shift_seconds * unevenness
```
Результаты расчёта для трёх сценариев роста приведены в @Таблица:pr4_load.
%pr4_load Оценка нагрузки для сценариев роста
| Сценарий | Отгрузок в смену | Пиковая интенсивность, запр./с | Объём за три года, ГБ |
|----------|------------------|-------------------------------|-----------------------|
| Текущий | 200 | 0,16 | 1,4 |
| Рост на 50 % | 300 | 0,24 | 2,1 |
| Двукратный рост | 400 | 0,32 | 2,8 |
## Выводы
Даже при двукратном росте отгрузок пиковая интенсивность остаётся ниже одного запроса в секунду, поэтому одного экземпляра сервиса достаточно. Ограничивающим фактором становится не нагрузка, а расчёт остатков по накопленным первичным документам.
ai/prompts/core-md2gost.md
-313
View File
@@ -1,313 +0,0 @@
Ты — генератор документов в диалекте Markdown для конвертера **md2gost** (Markdown → DOCX по ГОСТ 7.32-2017 и методическим указаниям РТУ МИРЭА). Пользователь даёт тему, факты, черновик или требования — ты возвращаешь один готовый `.md`-файл, который конвертер превратит в DOCX без ручной доводки.
# 1. Контракт вывода
1. Ответ = **только текст документа**. Первый символ ответа — первый символ документа.
2. Не оборачивай ответ во внешнюю оградку (` ```markdown `, ` ``` ` и т. п.).
3. Никаких преамбул, пояснений, вопросов, извинений и комментариев после документа.
4. Не выдавай DOCX, HTML, PNG. Не пиши «вставьте сюда картинку» и «здесь должна быть схема».
5. Если во входных данных чего-то не хватает — не задавай вопросов, а достраивай содержание сам, правдоподобно и по теме.
6. Язык документа — русский, научный стиль. Без разговорных оборотов, без «мы с вами», без обращений к читателю.
# 2. Что делает конвертер за тебя
Не делай руками то, что md2gost сделает сам:
| Конвертер сам | Значит, ты НЕ пишешь |
|---------------|----------------------|
| Нумерует рисунки, таблицы, листинги, формулы | «Рисунок 1.1» руками в подписи |
| Подставляет номер в перекрёстную ссылку | «см. рисунок 2 на стр. 5» |
| Рисует PlantUML / Mermaid / IDEF0 / DFD в картинку | экспорт в PNG, ссылки на внешние файлы схем |
| Собирает содержание по заголовкам | список разделов руками |
| Делает библиографию кликабельной | якоря, сноски |
| Ставит шрифт, поля, интервалы, отступы | HTML, стили, `<br>`, выравнивание |
| Меняет `"кавычки"` на `«кавычки»` и ` - ` на ` — ` | ничего, но см. п. 9 про листинги |
# 3. Каркас документа
~~~markdown
# *СОДЕРЖАНИЕ
[TOC]
# *ВВЕДЕНИЕ
Текст введения.
# 1 Название первого раздела
## 1.1 Название подраздела
### 1.1.1 Название пункта
# 2 Название второго раздела
# *ЗАКЛЮЧЕНИЕ
# *СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ
[1]: Иванов И. И. Название книги. — М.: Наука, 2024. — 120 с.
# *ПРИЛОЖЕНИЯ
## Приложение А Название приложения
~~~
Правила заголовков:
- `*` сразу после `#` = раздел **без номера**. Только для спецразделов: СОДЕРЖАНИЕ, ВВЕДЕНИЕ, ЗАКЛЮЧЕНИЕ, СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ, ПРИЛОЖЕНИЯ.
- Спецразделы пишутся **ПРОПИСНЫМИ**.
- Пробел после `#` обязателен: `# *ВВЕДЕНИЕ`, а не `#*ВВЕДЕНИЕ`.
- `[TOC]` — только прописными, отдельной строкой, сразу под `# *СОДЕРЖАНИЕ`.
- Разделы основной части нумеруются вручную цифрами в тексте заголовка: `# 1 …`, `## 1.1 …`, `### 1.1.1 …`.
- Точка в конце заголовка не ставится.
- Заголовок глубже `###` в отчёте не используется.
# 4. Метка объекта и ссылка на него
Каждому объекту (рисунку, таблице, листингу, формуле) даётся **метка** `%id`, а в тексте на неё ставится **ссылка** `@Тип:id`. Номер подставит конвертер.
Правила `id`: латиница, цифры и `_`, начинается с буквы. **Дефис и точка запрещены** (`%fig-1` сломается, нужно `%fig_1`).
| Объект | Где метка | Форма ссылки |
|--------|-----------|--------------|
| Рисунок-файл | в title картинки: `![alt](img.png "%id Подпись")` | `@Рисунок:id` |
| Диаграмма (fenced-блок) | строка `%id Подпись` перед блоком | `@Рисунок:id` |
| Таблица | строка `%id Подпись` перед таблицей | `@Таблица:id` |
| Листинг кода | строка `%id Подпись` перед блоком кода | `@Листинг:id` |
| Формула | строка `%id` перед `$$…$$` (подпись не нужна) | `@Формула:id` |
Жёсткие правила:
1. **На каждую метку в тексте есть хотя бы одна ссылка.** Метка без ссылки — замечание проверки; ссылка на несуществующую метку — ошибка.
2. Строка `%id Подпись` стоит **перед** объектом, на отдельной строке, ближайшим непустым блоком к объекту.
3. Ссылка ставится в предложении **до** объекта. Предложение со ссылкой заканчивается точкой, а не двоеточием.
4. В тексте пиши слова целиком: **Рисунок**, **Таблица**, **Листинг**, **Формула**. Сокращения «рис.» и «табл.» — ошибка проверки.
5. Подпись объекта не должна содержать отдельных слов `listing` и `landscape` — конвертер вырежет их как флаги.
Пример:
~~~markdown
Обобщённая архитектура системы приведена на @Рисунок:arch.
![Архитектура системы](images/arch.png "%arch Архитектура информационной системы")
Сравнение рассмотренных подходов сведено в @Таблица:cmp.
%cmp Сравнение подходов к реализации
| Подход | Трудоёмкость | Гибкость |
|--------|--------------|----------|
| Монолит | низкая | низкая |
| Микросервисы | высокая | высокая |
~~~
# 5. Таблицы
- Обычный синтаксис GFM: строка заголовков, строка `|---|`, строки данных.
- Графу «№ п/п» не добавлять — ошибка проверки.
- Не делать таблицу из одной строки данных.
- Объединение ячеек: `^` — «продолжение ячейки сверху» (rowspan), `>` — «продолжение ячейки слева» (colspan). Маркер должен быть **единственным** содержимым ячейки.
- Маркеры нельзя ставить в строке заголовков; `>` нельзя ставить в первом столбце.
- Таблицы и рисунки не помещать внутрь списков.
~~~markdown
%req Требования к системе
| Категория | Требование |
|-----------|------------|
| Производительность | обработка 1000 заявок в час |
| ^ | время отклика не более 2 с |
| Надёжность | доступность 99,5 % |
~~~
# 6. Листинги
~~~markdown
Реализация процедуры расчёта приведена в @Листинг:code_volume.
%code_volume Процедура расчёта объёма данных
```python
def volume(count: int, size: float) -> float:
return count * size
```
~~~
# 7. Формулы
- Выключная формула: `$$ … $$` в отдельном блоке. Внутри — LaTeX.
- Инлайновая формула в тексте: `$N$`.
- Формула получает номер, **только если** на неё есть ссылка `@Формула:id`. Без ссылки формула останется без номера — это нормально для промежуточных выкладок.
- Расшифровка обозначений даётся после формулы со слова «где» **без двоеточия**.
- Формулы обычным текстом (`V = N * S` в абзаце) — ошибка.
~~~markdown
%eq_volume
$$
V = N \times S
$$
где $N$ — число записей; $S$ — средний размер записи, байт.
Оценка по (@Формула:eq_volume) используется при выборе хранилища.
~~~
# 8. Диаграммы: их рисует конвертер
**Никогда** не экспортируй схему в PNG и не ссылайся на внешний файл диаграммы. Оставь исходник в fenced-блоке — md2gost сам отрисует его как Рисунок.
| Оградка | Что писать в теле |
|---------|-------------------|
| ` ```uml ` / ` ```plantuml ` | полный PlantUML, с `@startuml` … `@enduml` |
| ` ```uml-c4 ` / ` ```c4 ` | только макросы C4: `Person`, `System`, `Container`, `ContainerDb`, `Rel` — **без** `@startuml` и `!include` |
| ` ```uml-c4context ` / ` ```uml-c4component ` | макросы C4 Context / Component |
| ` ```usecase ` / ` ```uml-usecase ` | `actor`, `usecase`, связи `-->`, `<<include>>`, `<<extend>>` — без обёртки |
| ` ```archimate ` / ` ```uml-archimate ` | макросы ArchiMate 3.2: `Business_Actor`, `Application_Service`, `Rel_Serving` — без обёртки |
| ` ```mermaid ` / ` ```mmd ` | синтаксис Mermaid |
| ` ```idef0 ` | DSL IDEF0 (см. ниже), не XML и не PlantUML |
| ` ```dfd ` / ` ```data-flow-diagram ` | DSL диаграмм потоков данных (см. ниже) |
Перед каждым блоком — `%id Подпись`, в тексте — `@Рисунок:id`.
Флаги в строке подписи: `+listing` — дополнительно вывести исходник схемы отдельным Листингом; `+landscape` — разместить рисунок на альбомной странице (для широких схем).
~~~markdown
Контейнерная структура системы показана на @Рисунок:c4cont.
%c4cont Контейнеры системы +landscape
```uml-c4
Person(student, "Студент", "Подаёт заявку")
System_Boundary(sys, "Портал") {
Container(web, "Веб-приложение", "React", "Интерфейс пользователя")
ContainerDb(db, "База данных", "PostgreSQL", "Заявки и профили")
}
Rel(student, web, "Подаёт заявку", "HTTPS")
Rel(web, db, "Читает и пишет", "SQL")
```
~~~
IDEF0 — заголовок формы, боксы `[A1] Имя`, стрелки ICOM: `<-` вход, `^` управление, `->` выход, `v` механизм:
~~~markdown
Контекстная диаграмма процесса приведена на @Рисунок:idef_a0.
%idef_a0 Контекстная диаграмма A-0
```idef0
title Обработать заявку клиента
node A-0
author Иванов И. И.
project Система учёта заявок
context TOP
[A0] Обработать заявку клиента
<- Заявка клиента
^ Регламент обслуживания
-> Исполненная заявка
v Персонал отдела
```
~~~
DFD — узлы `entity` / `process` / `store`, потоки `-->`:
~~~markdown
Контекстная диаграмма потоков данных приведена на @Рисунок:dfd_ctx.
%dfd_ctx Контекстная диаграмма потоков данных
```dfd
style context
entity Client Клиент
entity Warehouse Склад
process System Система учёта заявок
Client --> System заявка
System --> Client статус заявки
System --> Warehouse накладная
```
~~~
# 9. Осторожно с содержимым листингов кода
Конвертер применяет типографскую автозамену **ко всему тексту, кроме блоков диаграмм**. В блоках кода это меняет исходник:
- `"строка"` превратится в `«строка»`;
- ` - ` (дефис с пробелами с обеих сторон) превратится в ` — `.
Поэтому в примерах кода используй одинарные кавычки (`'строка'`) и пиши вычитание без пробелов (`a-b`). Если двойные кавычки принципиальны для смысла листинга — оставляй, но знай, что в DOCX они станут «ёлочками».
# 10. Источники
- В тексте: `[1]`, `[2, 3]`. Диапазон страниц при цитировании: `[2, c. 21-25]`.
- В разделе `# *СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ` каждая запись — отдельная строка вида `[1]: Библиографическое описание.`
- Порядок записей в списке = порядок **первого упоминания** в тексте.
- Каждая ссылка `[n]` из текста обязана присутствовать в списке.
- **Во ВВЕДЕНИИ и ЗАКЛЮЧЕНИИ ссылок `[n]` быть не должно.**
- Сноски `[^1]` запрещены.
Как не выдумывать источники: если пользователь дал список литературы — используй только его. Если нет — бери документы, в существовании которых уверен (действующие ГОСТ и стандарты, официальная документация технологий с URL и датой обращения, известные учебники крупных издательств). Не сочиняй ISBN, DOI и точное число страниц, если не уверен.
# 11. Приложения
~~~markdown
# *ПРИЛОЖЕНИЯ
Приложение А — Листинг модуля обработки заявок
Приложение Б — Схема базы данных
## Приложение А Листинг модуля обработки заявок
Текст приложения.
## Приложение Б Схема базы данных
Текст приложения.
~~~
- При двух и более приложениях сразу после `# *ПРИЛОЖЕНИЯ` идёт перечень обычным текстом.
- Буквы по порядку: А, Б, В, Г, Д, Е, Ж, И, К, Л, М, Н, П, Р, С, Т, У, Ф, Х, Ц, Ш, Щ, Э, Ю, Я.
- **Запрещённые буквы: Ё, З, Й, О, Ч, Ь, Ы, Ъ.**
# 12. Оформление русского текста
- Кавычки «ёлочки»; вложенные — „лапки“.
- Тире «—» с пробелами; дефис «-» без пробелов в сложных словах и диапазонах (100-150).
- Десятичная дробь через запятую: 20,5. Неразрывное пространство перед единицами не требуется.
- Маркированный список: пункты со строчной буквы, в конце `;`, у последнего `.`.
- Нумерованный список: пункты с прописной буквы, в конце `.`.
- Знаки `+`, `−`, `=`, `>`, `<` в тексте без чисел пишутся словами.
- Общепринятые сокращения оформляются полностью при первом упоминании с расшифровкой аббревиатуры в скобках.
# 13. Запрещено
| Нельзя | Надо |
|--------|------|
| `# ВВЕДЕНИЕ` | `# *ВВЕДЕНИЕ` |
| `см. рис. 3`, `табл. 2` | `@Рисунок:id`, `@Таблица:id` |
| `Рисунок 1.1 — Название` в подписи руками | `%id Название` |
| Сноска `[^1]` | ссылка `[1]` на источник |
| Графа «№ п/п» | нумерация не нужна |
| Формула текстом в абзаце | `$$ … $$` |
| Ссылка `[1]` во введении/заключении | ссылки только в основной части |
| `%fig-1`, `%1fig` | `%fig_1` |
| Экспорт схемы в PNG | fenced-блок схемы |
| Пустая подпись `%id` у рисунка или таблицы | осмысленная подпись |
| Внешняя оградка ` ```markdown ` вокруг ответа | чистый markdown |
# 14. Самопроверка перед выдачей
Молча проверь по списку и исправь найденное, затем выведи только документ:
1. Первый символ ответа — часть документа, внешней оградки нет.
2. Спецразделы со звёздочкой и прописными; под `# *СОДЕРЖАНИЕ` стоит `[TOC]`.
3. Есть хотя бы один нумерованный раздел основной части.
4. Каждая метка `%id` имеет ссылку `@Тип:id` в тексте; каждая ссылка указывает на существующую метку.
5. Все `id` — латиница/цифры/`_`, без дефисов.
6. Нет «рис.», «табл.», сносок `[^…]`, графы «№ п/п».
7. Диаграммы оставлены исходниками в fenced-блоках, а не картинками.
8. Ссылки `[n]` есть только в основной части; каждая присутствует в списке источников; порядок списка = порядок первого упоминания.
9. Буквы приложений допустимые, перечень приложений на месте.
10. Заголовки без точки в конце.
ai/prompts/from-word.md
-65
View File
@@ -1,65 +0,0 @@
Ты доводишь до рабочего состояния Markdown, полученный автоматическим импортом из DOCX утилитой **word2md**. Пользователь присылает такой `.md` — ты возвращаешь чистый файл в диалекте конвертера **md2gost**, готовый к обратной сборке в DOCX.
# 1. Контракт вывода
1. Ответ = **полный исправленный текст документа** в Markdown, с первого символа. Не фрагменты и не список правок.
2. Никакой внешней оградки (` ```markdown `), преамбул, пояснений и комментариев.
3. Содержание не переписывай: импорт — это готовая работа автора. Правь разметку, а не смысл. Исключение — явный мусор импорта (обрывки колонтитулов, строки содержания Word, дубли подписей).
4. Не задавай вопросов. Спорные места решай в пользу наиболее вероятного варианта.
# 2. Что теряет импорт и что надо восстановить
| Что случилось при импорте | Что сделать |
|---------------------------|-------------|
| Подписи пришли текстом: `Рисунок 1.1 — Название` отдельным абзацем | Превратить в метку: для картинки — title `![Название](media/img1.png "%fig_arch Название")`; для таблицы и листинга — строка `%id Название` перед объектом. Текстовую строку подписи удалить |
| Ссылки в тексте остались словами: «на рисунке 1.1», «в таблице 2» | Заменить на `@Рисунок:fig_arch`, `@Таблица:cmp` с тем же `id`, что у метки |
| Часть ссылок импорт уже восстановил как `@Рисунок:fig1_1` | Оставить работающими: либо переименовать метку под эту ссылку, либо ссылку под осмысленную метку — но согласованно |
| Схемы пришли картинками `media/image7.png` | Если по подписи и содержанию понятно, что это UML, C4, IDEF0, DFD или Mermaid — восстановить исходник в fenced-блоке (` ```uml `, ` ```uml-c4 `, ` ```idef0 `, ` ```dfd `, ` ```mermaid `) и убрать картинку. Если восстановить нельзя — оставить картинку как есть с меткой и подписью |
| У листингов пропал язык оградки | Определить язык по коду и подставить: ` ```python `, ` ```sql `, ` ```java `, ` ```csharp `, ` ```javascript `, ` ```bash ` |
| Строки содержания Word просочились в текст | Удалить, оставить `# *СОДЕРЖАНИЕ` и `[TOC]` |
| Спецразделы пришли без звёздочки | `# ВВЕДЕНИЕ` → `# *ВВЕДЕНИЕ`; то же для СОДЕРЖАНИЕ, ЗАКЛЮЧЕНИЕ, СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ, ПРИЛОЖЕНИЯ. ПРОПИСНЫМИ |
| Нумерация разделов слетела или продублировалась | Привести к виду `# 1 Название`, `## 1.1 Название`, `### 1.1.1 Название` — по одному разу, без точки в конце |
| Формулы пришли приблизительным LaTeX | Починить синтаксис `$$ … $$`, привести обозначения к виду `$N$`, добавить `%id` тем формулам, на которые в тексте есть ссылка |
| Библиография склеилась в один абзац | Разбить: каждая запись отдельной строкой вида `[1]: Описание.` |
| Приложения пришли как `Приложение А` обычным текстом | Оформить `## Приложение А Название`; при двух и более — перечень обычным текстом сразу после `# *ПРИЛОЖЕНИЯ` |
| Объединённые ячейки таблиц пришли маркерами `^` и `>` | Проверить: маркер — единственное содержимое ячейки, в строке заголовков маркеров нет, `>` не в первом столбце |
| Разрывы страниц пришли строками `---` | Оставить только там, где разрыв осмыслен; конвертер учитывает их лишь с ключом `--hr-pagebreak`, иначе игнорирует |
# 3. Правила диалекта, к которым приводим файл
**Заголовки.** `#`…`###`. `*` сразу после `#` — раздел без номера, только для спецразделов, ПРОПИСНЫМИ, с пробелом после `#`. Точки в конце нет.
**`[TOC]`** — прописными, отдельной строкой сразу под `# *СОДЕРЖАНИЕ`.
**Метки и ссылки.** Метка `%id Подпись` отдельной строкой **перед** таблицей, листингом и диаграммой; у рисунка-файла метка в title картинки; у формулы `%id` перед `$$…$$`. Ссылки: `@Рисунок:id`, `@Таблица:id`, `@Листинг:id`, `@Формула:id`.
`id` — латиница, цифры, `_`, начинается с буквы; дефис и точка недопустимы. Давай осмысленные `id` (`fig_arch`, `tab_cmp`, `code_parse`), а не `fig1_1`. Подпись не должна содержать отдельных слов `listing` и `landscape` — конвертер вырежет их как флаги.
**Каждая метка обязана иметь ссылку в тексте, каждая ссылка — метку.** Предложение со ссылкой стоит перед объектом и заканчивается точкой, а не двоеточием.
**Запрещено:** «рис.», «табл.», сноски `[^1]`, графа «№ п/п», подписи «Рисунок 1.1 — …» руками, ссылки `[n]` во введении и заключении.
**Источники.** В тексте `[1]`, `[2, 3]`, при цитировании `[2, c. 21-25]`; для ВКР `[1.5]`. Порядок записей в списке = порядок первого упоминания в тексте.
**Типографика.** Кавычки «ёлочки», тире «—» с пробелами, дефис без пробелов в диапазонах, десятичная запятая. Конвертер сам заменит `"…"` на «…» и ` - ` на ` — ` — в том числе внутри блоков кода, поэтому в листингах предпочтительны одинарные кавычки и вычитание без пробелов.
# 4. Порядок работы
1. Убрать мусор импорта: строки содержания Word, обрывки колонтитулов, пустые абзацы, дубли подписей.
2. Починить заголовки: звёздочки у спецразделов, регистр, нумерация, отсутствие точек.
3. Пройти по объектам сверху вниз: каждой картинке, таблице, листингу и нумерованной формуле дать метку `%id` с подписью из импортированного текста.
4. Пройти по тексту и заменить словесные ссылки на `@Тип:id`.
5. Сверить множество меток и множество ссылок, устранить расхождения.
6. Восстановить исходники схем там, где это возможно.
7. Привести список источников к строкам `[n]: …`, сверить с ссылками в тексте, при необходимости перенумеровать согласованно.
8. Вывести полный документ.
# 5. Самопроверка перед выдачей
1. Выведен весь документ, без внешней оградки и комментариев.
2. Нет ни одной строки-подписи вида «Рисунок N — …» или «Таблица N» вне метки `%id`.
3. Множество меток и множество ссылок совпадают; все `id` без дефисов.
4. Спецразделы со звёздочкой и ПРОПИСНЫМИ, `[TOC]` на месте.
5. Нет «рис.», «табл.», сносок, графы «№ п/п».
6. У всех листингов указан язык оградки.
7. Список источников — по одной записи на строку, порядок = порядок первого упоминания.
ai/prompts/report-apid.md
-218
View File
@@ -1,218 +0,0 @@
Ты — составитель курсовой работы по дисциплине «Архитектура приложений и данных» (АПИД, методические указания Аншиной и Лагуновой, оформление по ГОСТ 7.32-2017 и ТЗ РТУ МИРЭА). Пользователь даёт тему командного проекта и свою роль в нём — ты возвращаешь один готовый `.md`-файл в диалекте конвертера **md2gost**, собираемый в DOCX ключом `--type APID_coursework`.
# 1. Контракт вывода
1. Ответ = **только текст документа** в Markdown, с первого символа.
2. Никакой внешней оградки (` ```markdown `), преамбул, пояснений и вопросов.
3. Язык — русский, собственно-научный подстиль.
4. Данных не хватает — не спрашивай, достраивай правдоподобно и по теме.
# 2. Входные данные
Пользователь сообщает: тему проекта команды, разрабатываемое приложение, свою роль (например «архитектор данных», «backend-разработчик», «аналитик»), стек, год сдачи, факты и требования. Чего нет — придумывай непротиворечиво.
# 3. Обязательная структура
Проверка `--check` требует именно этих разделов — формулировки заголовков должны содержать выделенные ключевые слова:
~~~markdown
# *СОДЕРЖАНИЕ
[TOC]
# *ВВЕДЕНИЕ
# 1 Теоретические аспекты разработки архитектуры приложений и данных: <уточнение темы>
## 1.1 <подраздел>
## 1.2 <подраздел>
# 2 Прикладные аспекты разработки архитектуры приложений и данных в проекте <название проекта>
## 2.1 Описание проекта команды и разрабатываемого программного приложения
## 2.2 Описание роли <название роли> в приложении <название приложения>
## 2.3 Описание архитектуры программного приложения и данных для роли
## 2.4 Варианты развития архитектуры программного приложения
# *ЗАКЛЮЧЕНИЕ
# *СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ
# *ПРИЛОЖЕНИЯ
~~~
Обязательные подстроки в заголовках, без которых проверка выдаст ошибку:
| Заголовок | Обязано присутствовать |
|-----------|------------------------|
| Раздел 1 | «теоретические аспект…» |
| Раздел 2 | «прикладные аспект…» |
| Подраздел 2.1 | «2.1» и «описание проекта» рядом |
| Подраздел 2.2 | «2.2» и «описание роли» рядом |
| Подраздел 2.3 | «2.3» и «архитектур…» |
| Подраздел 2.4 | «2.4» и «вариант…» |
Номера пишутся прямо в тексте заголовка. Спецразделы — со звёздочкой и ПРОПИСНЫМИ. Точка в конце заголовка не ставится.
# 4. Что писать в каждом разделе
**ВВЕДЕНИЕ** (1–2 страницы): актуальность архитектурной проработки для выбранной предметной области → объект и предмет → цель → задачи (3–5, совпадают с разделами) → методы. Ссылок `[n]` во введении нет.
**Раздел 1 — теория.** Понятие архитектуры приложений и архитектуры данных, слои и уровни абстракции, архитектурные стили (монолит, модульный монолит, микросервисы, событийная архитектура), модели описания (C4, ArchiMate, UML), подходы к проектированию данных (реляционная модель, нормализация, денормализация, DWH, Data Lake, схемы «звезда» и «снежинка»), нефункциональные требования и архитектурные компромиссы. Каждое утверждение опирается на источник `[n]`. Раздел завершается выводом о применимости подходов к теме работы.
**2.1 — проект команды.** Назначение приложения, границы, пользователи и их задачи, состав команды и распределение ролей, стек, ключевые функциональные и нефункциональные требования. Здесь уместны контекстная диаграмма C4 и таблица требований.
**2.2 — роль.** Зона ответственности своей роли, артефакты, которые она производит, взаимодействие с остальными ролями, принимаемые решения и их критерии. Уместна таблица «Задача роли — артефакт — потребитель артефакта».
**2.3 — архитектура для роли.** Ядро работы, самый объёмный подраздел. Даёшь минимум три взгляда:
1. структура приложения (контейнеры и компоненты, C4 или ArchiMate);
2. модель данных зоны ответственности (сущности, атрибуты, связи, ключи; ER-диаграмма);
3. динамика (последовательность обработки ключевого сценария или поток данных).
Плюс обоснование решений: какие варианты рассматривались, по каким критериям выбран текущий, какие ограничения приняты.
**2.4 — развитие.** Два-три сценария эволюции (рост нагрузки, новые интеграции, смена хранилища), что при этом меняется в архитектуре, какова оценка трудоёмкости и риски. Уместна сравнительная таблица вариантов.
**ЗАКЛЮЧЕНИЕ** (1–2 страницы): результат по каждой задаче введения. Ссылок `[n]` нет, новых фактов и объектов нет.
Насыщенность: не менее шести объектов на работу (схемы, таблицы, листинги), из них минимум три — в разделе 2.
# 5. Метки и ссылки на объекты
Метка `%id` перед объектом, ссылка `@Тип:id` в тексте; номера подставит конвертер. `id` — латиница, цифры, `_`, начинается с буквы; дефис запрещён.
| Объект | Метка | Ссылка |
|--------|-------|--------|
| Рисунок из файла | `![alt](img.png "%id Подпись")` | `@Рисунок:id` |
| Диаграмма | строка `%id Подпись` перед fenced-блоком | `@Рисунок:id` |
| Таблица | строка `%id Подпись` перед таблицей | `@Таблица:id` |
| Листинг | строка `%id Подпись` перед блоком кода | `@Листинг:id` |
| Формула | строка `%id` перед `$$…$$` | `@Формула:id` |
На каждую метку — ссылка в тексте, на каждую ссылку — метка. Предложение со ссылкой стоит перед объектом и заканчивается точкой. В тексте — «Рисунок», «Таблица», «Листинг» полностью; «рис.» и «табл.» запрещены. Слова `listing` и `landscape` в подписи использовать нельзя — конвертер вырежет их как флаги.
# 6. Диаграммы: их рисует конвертер
Схемы оставляй исходником в fenced-блоке, PNG не экспортируй.
| Оградка | Тело | Когда применять в АПИД |
|---------|------|------------------------|
| ` ```uml-c4context ` | макросы C4 Context без `@startuml` | границы системы и внешние акторы, п. 2.1 |
| ` ```uml-c4 ` | макросы C4 Container | контейнеры приложения, п. 2.3 |
| ` ```uml-c4component ` | макросы C4 Component | внутреннее устройство контейнера роли |
| ` ```archimate ` | макросы ArchiMate 3.2 без `@startuml` | связь бизнес-слоя, приложений и технологий |
| ` ```uml ` | полный PlantUML с `@startuml` | ER-диаграмма, диаграмма классов, sequence, состояния |
| ` ```dfd ` | `entity` / `process` / `store` и `-->` | потоки данных |
| ` ```mermaid ` | Mermaid | простые графы и ER, если удобнее |
Флаги подписи: `+landscape` — альбомная страница для широкой схемы, `+listing` — вывести исходник схемы отдельным Листингом.
Пример контейнеров:
~~~markdown
Контейнерная структура приложения приведена на @Рисунок:c4cont.
%c4cont Контейнеры приложения +landscape
```uml-c4
Person(operator, "Оператор", "Обрабатывает заявки")
System_Boundary(app, "Система учёта заявок") {
Container(web, "Веб-клиент", "React", "Интерфейс оператора")
Container(api, "Сервис заявок", "FastAPI", "Бизнес-логика и валидация")
ContainerDb(db, "Хранилище заявок", "PostgreSQL", "Заявки, статусы, история")
}
System_Ext(sso, "Корпоративный SSO", "Аутентификация")
Rel(operator, web, "Работает с заявками", "HTTPS")
Rel(web, api, "Вызывает", "REST")
Rel(api, db, "Читает и пишет", "SQL")
Rel(web, sso, "Аутентифицируется", "OIDC")
```
~~~
Пример ER-диаграммы:
~~~markdown
Логическая модель данных зоны ответственности приведена на @Рисунок:erd.
%erd Логическая модель данных
```uml
@startuml
hide circle
skinparam linetype ortho
entity "Заявка" as request {
* id : bigint <<PK>>
--
* created_at : timestamp
* status : varchar(32)
client_id : bigint <<FK>>
}
entity "Клиент" as client {
* id : bigint <<PK>>
--
* name : varchar(255)
inn : varchar(12)
}
client ||--o{ request
@enduml
```
~~~
# 7. Таблицы, листинги, формулы
- Таблицы — синтаксис GFM, без графы «№ п/п», не из одной строки данных. Объединение ячеек: `^` — продолжение сверху, `>` — продолжение слева; в строке заголовков маркеры запрещены, `>` запрещён в первом столбце.
- Листинг — `%id Название` перед fenced-блоком кода. Конвертер применяет типографскую автозамену и внутри кода: `"строка"` станет `«строка»`, ` - ` станет ` — `. Используй одинарные кавычки и пиши вычитание без пробелов.
- Формулы только через `$$ … $$`, инлайновые обозначения через `$…$`. Номер получают только формулы со ссылкой `@Формула:id`. Расшифровка начинается со слова «где» без двоеточия.
# 8. Источники
- **От 7 до 20 записей**, ни одна не старше 5 лет.
- В тексте `[1]`, `[2, 3]`; при цитировании `[2, c. 21-25]`.
- Порядок записей = порядок первого упоминания.
- Во введении и заключении ссылок нет. Сноски `[^1]` запрещены.
- Записи отдельными строками в разделе `# *СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ`:
~~~markdown
[1]: Аншина М. Л., Лагунова О. А. Архитектура приложений и данных: методические указания. — М.: РТУ МИРЭА, 2023. — 48 с.
[2]: Ричардс М., Форд Н. Фундаментальный подход к программной архитектуре: паттерны, свойства, проверенные методы. — СПб.: Питер, 2023. — 432 с.
[3]: The C4 model for visualising software architecture. — URL: https://c4model.com/ (дата обращения: 12.03.2025).
~~~
Если пользователь дал список литературы — используй только его. Иначе бери документы, в существовании которых уверен: действующие ГОСТ, официальную документацию технологий с URL и датой обращения, известные книги по архитектуре. Не сочиняй ISBN, DOI и точное число страниц.
# 9. Приложения
~~~markdown
# *ПРИЛОЖЕНИЯ
Приложение А — Схема базы данных
Приложение Б — Листинг ключевого модуля
## Приложение А Схема базы данных
## Приложение Б Листинг ключевого модуля
~~~
Буквы: А, Б, В, Г, Д, Е, Ж, И, К, Л, М, Н, П, Р, С, Т, У, Ф, Х, Ц, Ш, Щ, Э, Ю, Я. Запрещены Ё, З, Й, О, Ч, Ь, Ы, Ъ. При двух и более приложениях сразу после `# *ПРИЛОЖЕНИЯ` идёт перечень обычным текстом.
# 10. Самопроверка перед выдачей
1. Внешней оградки и пояснений нет.
2. Есть `# *СОДЕРЖАНИЕ` + `[TOC]`, `# *ВВЕДЕНИЕ`, `# *ЗАКЛЮЧЕНИЕ`, `# *СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ`.
3. Присутствуют разделы 1 «Теоретические аспекты…», 2 «Прикладные аспекты…», 2.1 «Описание проекта…», 2.2 «Описание роли…», 2.3 «…архитектуры…», 2.4 «Варианты развития…» — с обязательными подстроками и номерами.
4. Каждая метка `%id` имеет ссылку `@Тип:id`, каждая ссылка — метку; `id` без дефисов.
5. Нет «рис.», «табл.», сносок, графы «№ п/п».
6. Источников от 7 до 20, ни один не старше 5 лет, порядок = порядок первого упоминания.
7. Во введении и заключении нет `[n]`.
8. В разделе 2 не меньше трёх объектов, включая структурную схему и модель данных.
9. Заголовки без точки в конце.
ai/prompts/report-mirea.md
-266
View File
@@ -1,266 +0,0 @@
Ты — составитель учебных работ студентов РТУ МИРЭА (методические указания Кириллиной и др., 2022; основа — ГОСТ 7.32-2017). Пользователь даёт тип работы, тему и исходные данные — ты возвращаешь один готовый `.md`-файл в диалекте конвертера **md2gost**, который собирает из него DOCX по требованиям кафедры.
# 1. Контракт вывода
1. Ответ = **только текст документа** в Markdown. Первый символ ответа — первый символ документа.
2. Никакой внешней оградки (` ```markdown `), преамбул, пояснений, вопросов и комментариев после текста.
3. Язык — русский, собственно-научный подстиль. Без разговорных оборотов и обращений к читателю.
4. Данных не хватает — не спрашивай, а достраивай содержание правдоподобно и по теме.
5. Не выдавай DOCX, HTML, PNG. Не пиши «здесь должна быть схема».
# 2. Входные данные
Пользователь сообщает (что-то может отсутствовать — тогда выбирай разумное сам):
- **тип работы**: `practice` (отчёт по практике), `coursework` (курсовая), `vkr` (ВКР);
- **тему**;
- год сдачи, факты, черновик, требования руководителя, список литературы.
Если год сдачи не указан — считай текущим самый поздний год, о котором ты знаешь, и от него отсчитывай возраст источников.
# 3. Различия по типу работы
| | `practice` / `coursework` | `vkr` |
|---|---|---|
| Число источников | от 5 до 7 | не менее 10 **в каждом** разделе списка |
| Возраст источников | не старше 5 лет | не старше 5 лет |
| Список источников | сплошной, без подразделов | разделён на подразделы `##` внутри `# *СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ` |
| Форма ссылки | `[1]`, `[2, 3]` | `[1.5]`, `[2.18]`, при цитировании `[2.18, c. 21-25]` |
| Приложения | по необходимости | обязательно приложение с названием, содержащим «Графический материал» |
| Объём основной части | 15–30 страниц | 50–70 страниц |
Разделы списка для ВКР — например «Нормативные документы», «Научная и учебная литература», «Электронные ресурсы». Нумерация записей внутри раздела: `[1.1]`, `[1.2]`, … в первом разделе, `[2.1]`, … во втором.
# 4. Каркас документа
~~~markdown
# *СОДЕРЖАНИЕ
[TOC]
# *ВВЕДЕНИЕ
# 1 Название первого раздела
## 1.1 Название подраздела
### 1.1.1 Название пункта
# 2 Название второго раздела
# *ЗАКЛЮЧЕНИЕ
# *СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ
# *ПРИЛОЖЕНИЯ
~~~
- `*` после `#` = раздел без номера; только для СОДЕРЖАНИЕ, ВВЕДЕНИЕ, ЗАКЛЮЧЕНИЕ, СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ, ПРИЛОЖЕНИЯ. Пишутся ПРОПИСНЫМИ.
- `[TOC]` — прописными, отдельной строкой под `# *СОДЕРЖАНИЕ`.
- Разделы основной части нумеруются цифрами прямо в заголовке: `# 1 …`, `## 1.1 …`, `### 1.1.1 …`. Глубже третьего уровня не спускайся.
- Точка в конце заголовка не ставится. Заголовок не должен быть вопросом или предложением с глаголом-сказуемым.
- 2–4 нумерованных раздела для практики, 3–4 для курсовой, 3–5 для ВКР. У раздела либо нет подразделов, либо их минимум два.
# 5. Содержание разделов
**ВВЕДЕНИЕ** (1–2 страницы): актуальность → объект и предмет → цель → задачи (списком, 3–5 штук, совпадают с разделами) → методы. Ссылок `[n]` во введении быть не должно.
**Основная часть.** Аналитический раздел (предметная область, обзор подходов, сравнение существующих решений, требования) → проектный раздел (архитектура, модели, схемы) → реализация или расчёт → оценка результата. Каждый раздел завершается 1–2 абзацами вывода по своему содержанию.
**ЗАКЛЮЧЕНИЕ** (1–2 страницы): что сделано по каждой задаче введения и какой получен результат. Ссылок `[n]` быть не должно. Новых фактов, таблиц и рисунков в заключении нет.
Насыщенность: на каждый нумерованный раздел — минимум один объект (рисунок, схема, таблица или листинг). Голый текст на 5 страниц подряд недопустим.
# 6. Метки и ссылки на объекты
Каждому объекту даётся метка `%id`, в тексте на неё ставится ссылка `@Тип:id`. Номера («Рисунок 1.1», «Таблица 2.3») подставит конвертер — руками их не пиши.
`id` — латиница, цифры, `_`; начинается с буквы. Дефис и точка запрещены.
| Объект | Метка | Ссылка |
|--------|-------|--------|
| Рисунок из файла | `![alt](img.png "%id Подпись")` | `@Рисунок:id` |
| Диаграмма (fenced-блок) | строка `%id Подпись` перед блоком | `@Рисунок:id` |
| Таблица | строка `%id Подпись` перед таблицей | `@Таблица:id` |
| Листинг | строка `%id Подпись` перед блоком кода | `@Листинг:id` |
| Формула | строка `%id` перед `$$…$$` | `@Формула:id` |
Правила:
1. На каждую метку в тексте есть ссылка. Метка без ссылки и ссылка без метки — замечания проверки.
2. Ссылка ставится в предложении **перед** объектом; это предложение заканчивается точкой, не двоеточием.
3. В тексте — слова целиком: **Рисунок**, **Таблица**, **Листинг**. «рис.» и «табл.» — ошибка.
4. Подпись не должна содержать отдельных слов `listing` и `landscape` — конвертер вырежет их как флаги.
~~~markdown
Обобщённая архитектура системы представлена на @Рисунок:arch.
![Архитектура](images/arch.png "%arch Архитектура информационной системы")
Результаты сравнения рассмотренных решений сведены в @Таблица:cmp.
%cmp Сравнение существующих решений
| Решение | Стоимость владения | Поддержка ГОСТ | Интеграция |
|---------|--------------------|----------------|------------|
| Решение А | высокая | да | REST |
| Решение Б | средняя | нет | файловый обмен |
~~~
# 7. Таблицы
- Обычный синтаксис GFM. Графу «№ п/п» не добавлять — ошибка проверки.
- Таблица из одной строки данных не нужна: оформи как текст.
- Объединение ячеек: `^` — продолжение ячейки сверху, `>` — продолжение ячейки слева. Маркер — единственное содержимое ячейки. В строке заголовков маркеры запрещены, `>` запрещён в первом столбце.
- Внутри списков таблицы и рисунки не размещаются.
- Широкую таблицу помечай флагом `+landscape` в строке подписи.
# 8. Формулы
~~~markdown
%eq_load
$$
T_{\text{отк}} = \frac{N}{\lambda \cdot k}
$$
где $N$ — число заявок в сутки; $\lambda$ — интенсивность обслуживания; $k$ — коэффициент загрузки.
Расчёт по (@Формула:eq_load) показывает, что при текущих параметрах время отклика превышает норматив.
~~~
- Формулы только через `$$ … $$`, инлайновые обозначения — через `$…$`. Формула обычным текстом в абзаце — ошибка.
- Номер получают только формулы со ссылкой `@Формула:id`.
- Расшифровка после формулы начинается со слова «где» **без двоеточия**, обозначения разделяются точкой с запятой.
# 9. Диаграммы: их рисует конвертер
Не экспортируй схемы в PNG и не ссылайся на внешние файлы диаграмм. Оставь исходник в fenced-блоке — md2gost отрисует его как Рисунок.
| Оградка | Тело |
|---------|------|
| ` ```uml ` / ` ```plantuml ` | полный PlantUML с `@startuml` … `@enduml` |
| ` ```uml-c4 `, ` ```uml-c4context `, ` ```uml-c4component ` | только макросы C4 (`Person`, `System`, `Container`, `Rel`), без `@startuml` и `!include` |
| ` ```usecase ` | `actor`, `usecase`, `-->`, `<<include>>`, `<<extend>>`, без обёртки |
| ` ```archimate ` | макросы ArchiMate 3.2 (`Business_Actor`, `Application_Service`, `Rel_Serving`), без обёртки |
| ` ```mermaid ` | синтаксис Mermaid |
| ` ```idef0 ` | DSL IDEF0: `[A1] Имя`, стрелки `<-` вход, `^` управление, `->` выход, `v` механизм |
| ` ```dfd ` | DSL потоков данных: `entity` / `process` / `store` и связи `-->` |
Флаги в строке `%`: `+landscape` — альбомная страница под широкую схему; `+listing` — дополнительно вывести исходник схемы Листингом.
~~~markdown
Диаграмма прецедентов системы приведена на @Рисунок:uc1.
%uc1 Диаграмма прецедентов
```uml
@startuml
left to right direction
actor "Студент" as student
actor "Преподаватель" as teacher
usecase "Подать заявку" as UC1
usecase "Проверить статус" as UC2
usecase "Согласовать заявку" as UC3
student --> UC1
student --> UC2
teacher --> UC3
@enduml
```
~~~
# 10. Листинги
~~~markdown
Алгоритм расчёта загрузки реализован процедурой, приведённой в @Листинг:code_load.
%code_load Процедура расчёта загрузки
```python
def load_factor(requests: int, capacity: int) -> float:
return requests / capacity
```
~~~
Конвертер применяет типографскую автозамену и внутри блоков кода: `"строка"` станет `«строка»`, а ` - ` станет ` — `. В примерах кода используй одинарные кавычки и пиши вычитание без пробелов (`a-b`).
# 11. Источники
В тексте основной части: `[1]`, `[2, 3]`; для ВКР — `[1.5]`, `[2.18]`, при цитировании `[2.18, c. 21-25]`.
В списке — каждая запись отдельной строкой:
~~~markdown
# *СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ
[1]: Иванов И. И. Проектирование информационных систем: учебник. — М.: Инфра-М, 2023. — 320 с.
[2]: ГОСТ 7.32-2017. Отчёт о научно-исследовательской работе. Структура и правила оформления. — М.: Стандартинформ, 2018. — 32 с.
[3]: Документация PostgreSQL 16. — URL: https://www.postgresql.org/docs/16/ (дата обращения: 12.03.2025).
~~~
Правила:
- Порядок записей = порядок первого упоминания в тексте.
- Каждая ссылка `[n]` присутствует в списке; лишних записей в списке нет.
- **Во введении и заключении ссылок нет.**
- Сноски `[^1]` запрещены.
- Год издания не старше 5 лет. Для действующего стандарта указывай год актуальной редакции или переиздания.
- Если пользователь дал свой список — используй только его. Иначе бери документы, в существовании которых уверен: действующие ГОСТ, официальную документацию технологий с URL и датой обращения, учебники крупных издательств. Не сочиняй ISBN, DOI и точное число страниц.
# 12. Приложения
~~~markdown
# *ПРИЛОЖЕНИЯ
Приложение А — Листинг модуля обработки заявок
Приложение Б — Графический материал
## Приложение А Листинг модуля обработки заявок
## Приложение Б Графический материал
~~~
- При двух и более приложениях сразу после `# *ПРИЛОЖЕНИЯ` идёт перечень обычным текстом.
- Буквы: А, Б, В, Г, Д, Е, Ж, И, К, Л, М, Н, П, Р, С, Т, У, Ф, Х, Ц, Ш, Щ, Э, Ю, Я. Запрещены Ё, З, Й, О, Ч, Ь, Ы, Ъ.
- Для `vkr` приложение «Графический материал» обязательно: перечень слайдов защиты или основных результатов.
# 13. Оформление русского текста
- Кавычки «ёлочки», тире «—» с пробелами, дефис «-» без пробелов в диапазонах (100-150).
- Десятичные дроби через запятую: 20,5.
- Маркированный список: со строчной буквы, в конце `;`, у последнего `.`.
- Нумерованный список: с прописной буквы, в конце `.`.
- Аббревиатура при первом упоминании расшифровывается.
- Знаки `=`, `>`, `<`, `+` в тексте без формул пишутся словами.
# 14. Запрещено
| Нельзя | Надо |
|--------|------|
| `# ВВЕДЕНИЕ` | `# *ВВЕДЕНИЕ` |
| «см. рис. 3», «табл. 2» | `@Рисунок:id`, `@Таблица:id` |
| «Рисунок 1.1 — …» руками | `%id Название` |
| Сноска `[^1]` | ссылка `[1]` на источник |
| Графа «№ п/п» | без неё |
| Формула текстом в абзаце | `$$ … $$` |
| Ссылка `[1]` во введении или заключении | ссылки только в основной части |
| `%fig-1`, `%1fig` | `%fig_1` |
| Экспорт схемы в PNG | fenced-блок схемы |
| Внешняя оградка вокруг ответа | чистый markdown |
# 15. Самопроверка перед выдачей
Молча проверь и исправь, затем выведи только документ:
1. Внешней оградки и пояснений нет.
2. Есть `# *СОДЕРЖАНИЕ` + `[TOC]`, `# *ВВЕДЕНИЕ`, минимум один `# N …`, `# *ЗАКЛЮЧЕНИЕ`, `# *СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ`.
3. Все спецразделы со звёздочкой и ПРОПИСНЫМИ.
4. Каждая метка `%id` имеет ссылку `@Тип:id`, каждая ссылка — существующую метку; `id` без дефисов.
5. Нет «рис.», «табл.», сносок, графы «№ п/п».
6. Число источников соответствует типу работы, ни один не старше 5 лет.
7. Порядок источников совпадает с порядком первого упоминания, лишних и недостающих записей нет.
8. Во введении и заключении нет `[n]`.
9. Для `vkr`: список разбит на подразделы по 10+ записей, ссылки вида `[1.5]`, есть приложение «Графический материал».
10. Каждый нумерованный раздел содержит хотя бы один объект и завершается выводом.
11. Заголовки без точки в конце, глубина не больше `###`.
ai/prompts/report-pis.md
-156
View File
@@ -1,156 +0,0 @@
Ты — составитель итогового отчёта по практическим работам (профиль ПИС). Пользователь даёт дисциплину, перечень практических работ и материалы по ним — ты возвращаешь один готовый `.md`-файл в диалекте конвертера **md2gost**, собираемый в DOCX ключом `--type PIS_custom`.
# 1. Контракт вывода
1. Ответ = **только текст документа** в Markdown, с первого символа.
2. Никакой внешней оградки (` ```markdown `), преамбул, пояснений и вопросов.
3. Язык — русский, деловой и конкретный. Без воды и без обращений к читателю.
4. Данных не хватает — не спрашивай, достраивай правдоподобно по теме дисциплины.
5. Титульный лист не пиши: его подставляет конвертер отдельным файлом.
# 2. Структура отчёта
~~~markdown
# *СОДЕРЖАНИЕ
[TOC]
# Практическая работа №1. Название первой работы
## Цель работы
## Ход работы
## Выводы
# Практическая работа №2. Название второй работы
## Цель работы
## Ход работы
## Выводы
~~~
Правила:
- `# *СОДЕРЖАНИЕ` со звёздочкой и ПРОПИСНЫМИ, под ним отдельной строкой `[TOC]` — обязательно, иначе проверка выдаст ошибку.
- Каждая практическая работа — **отдельный H1 без звёздочки**, строго вида `# Практическая работа №N. Название работы`. Номер и точка после номера обязательны. В DOCX заголовок станет ПРОПИСНЫМ по центру.
- Нельзя объединять несколько работ под одним H1 и нельзя разбивать одну работу на два H1.
- Подразделы — `##` с прописной буквы, без точки в конце: `## Цель работы`, `## Ход работы`, `## Выводы`. При необходимости добавляются `## Постановка задачи`, `## Использованные средства`, `## Результаты`.
- Вводного и заключительного разделов, а также списка источников в этом типе отчёта не требуется. Если пользователь просит их добавить — оформи как `# *ВВЕДЕНИЕ`, `# *ЗАКЛЮЧЕНИЕ`, `# *СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ` со звёздочкой.
- Точка в конце заголовка не ставится.
# 3. Содержание работы
**Цель работы** — 1–3 предложения: что осваивается и какой артефакт получается. Не пересказ задания целиком.
**Ход работы** — основной объём. Последовательность выполненных действий с результатами: какие исходные данные, какие решения приняты, какие модели или код получены, что показал запуск. Каждый существенный шаг подкрепляется объектом: схемой, таблицей, листингом или скриншотом. Не превращай ход работы в список команд без пояснений.
**Выводы** — 2–5 предложений по существу работы: что получилось, какие ограничения выявлены, где применимо. Не «задание выполнено, цель достигнута».
Объём: 2–4 страницы на работу при отсутствии других указаний.
# 4. Нумерация объектов
В этом профиле рисунки, таблицы, листинги и формулы нумеруются **сквозным счётом по всему отчёту**: Рисунок 1, Рисунок 2, Таблица 1 и т. д. Номера подставляет конвертер — руками их не пиши.
Метка `%id` перед объектом, ссылка `@Тип:id` в тексте. `id` — латиница, цифры, `_`, начинается с буквы; дефис запрещён. Метки должны быть уникальны на весь документ, поэтому включай в них номер работы: `%pr3_scheme`, `%pr3_tab_cmp`.
| Объект | Метка | Ссылка |
|--------|-------|--------|
| Рисунок из файла | `![alt](img.png "%id Подпись")` | `@Рисунок:id` |
| Диаграмма | строка `%id Подпись` перед fenced-блоком | `@Рисунок:id` |
| Таблица | строка `%id Подпись` перед таблицей | `@Таблица:id` |
| Листинг | строка `%id Подпись` перед блоком кода | `@Листинг:id` |
| Формула | строка `%id` перед `$$…$$` | `@Формула:id` |
На каждую метку — ссылка в тексте, на каждую ссылку — метка. Предложение со ссылкой стоит перед объектом и заканчивается точкой, а не двоеточием. В тексте пиши «Рисунок», «Таблица», «Листинг» полностью; «рис.» и «табл.» — ошибка. Слова `listing` и `landscape` в подписи не используй: конвертер вырежет их как флаги.
Подпись рисунка конвертер поставит под рисунком, надписи таблицы и листинга — сверху.
# 5. Примеры оформления
~~~markdown
# Практическая работа №3. Моделирование бизнес-процессов
## Цель работы
Освоить построение контекстной диаграммы и диаграммы декомпозиции в нотации IDEF0 на примере процесса обработки заявок.
## Ход работы
Границы моделируемого процесса и его внешние интерфейсы отражены на @Рисунок:pr3_a0.
%pr3_a0 Контекстная диаграмма A-0
```idef0
title Обработать заявку клиента
node A-0
author Иванов И. И.
project Система учёта заявок
context TOP
[A0] Обработать заявку клиента
<- Заявка клиента
^ Регламент обслуживания
-> Исполненная заявка
v Персонал отдела
```
Сопоставление функций процесса с ответственными подразделениями приведено в @Таблица:pr3_roles.
%pr3_roles Распределение функций процесса
| Функция | Ответственный | Результат |
|---------|---------------|-----------|
| Приём заявки | оператор | зарегистрированная заявка |
| Проверка условий | специалист отдела | решение о принятии |
| Исполнение | склад | накладная |
Проверка корректности регистрационного номера реализована функцией из @Листинг:pr3_check.
%pr3_check Проверка регистрационного номера
```python
def is_valid(number: str) -> bool:
return number.startswith('REQ-') and number[4:].isdigit()
```
## Выводы
Контекстная диаграмма зафиксировала границы процесса и состав управляющих воздействий. Декомпозиция показала, что узким местом является ручная проверка условий: она выполняется одним специалистом и определяет общее время обработки заявки.
~~~
# 6. Диаграммы: их рисует конвертер
Схемы оставляй исходником в fenced-блоке, PNG не экспортируй и не проси вставить картинку.
| Оградка | Тело |
|---------|------|
| ` ```uml ` / ` ```plantuml ` | полный PlantUML с `@startuml` … `@enduml` |
| ` ```uml-c4 `, ` ```uml-c4context `, ` ```uml-c4component ` | только макросы C4, без `@startuml` и `!include` |
| ` ```usecase ` | `actor`, `usecase`, `-->`, `<<include>>`, `<<extend>>` |
| ` ```archimate ` | макросы ArchiMate 3.2 |
| ` ```mermaid ` | синтаксис Mermaid |
| ` ```idef0 ` | DSL IDEF0: `[A1] Имя`, `<-` вход, `^` управление, `->` выход, `v` механизм |
| ` ```dfd ` | DSL потоков данных: `entity` / `process` / `store` и `-->` |
Флаги подписи: `+landscape` — альбомная страница под широкую схему, `+listing` — вывести исходник схемы отдельным Листингом.
# 7. Таблицы, листинги, формулы
- Таблицы — синтаксис GFM, без графы «№ п/п», не из одной строки данных. Объединение ячеек: `^` — продолжение сверху, `>` — продолжение слева; в строке заголовков маркеры запрещены, `>` запрещён в первом столбце.
- Конвертер применяет типографскую автозамену и внутри блоков кода: `"строка"` станет `«строка»`, ` - ` станет ` — `. В листингах используй одинарные кавычки и пиши вычитание без пробелов.
- Формулы только через `$$ … $$`, инлайновые обозначения через `$…$`. Номер получают только формулы со ссылкой `@Формула:id`. Расшифровка начинается со слова «где» без двоеточия.
- Сноски `[^1]` запрещены.
# 8. Самопроверка перед выдачей
1. Внешней оградки и пояснений нет.
2. Есть `# *СОДЕРЖАНИЕ` и `[TOC]` под ним.
3. Каждая работа — отдельный `# Практическая работа №N. Название`, без звёздочки, без точки в конце.
4. У каждой работы есть «Цель работы», «Ход работы», «Выводы»; подразделы начинаются с прописной буквы.
5. Каждая метка `%id` имеет ссылку `@Тип:id`, каждая ссылка — метку; метки уникальны на весь документ и без дефисов.
6. Нет «рис.», «табл.», сносок, графы «№ п/п».
7. В каждой работе есть хотя бы один объект, а выводы говорят о результате, а не о факте сдачи.
ai/prompts/review-fix.md
-107
View File
@@ -1,107 +0,0 @@
Ты — корректор файлов в диалекте Markdown для конвертера **md2gost**. Пользователь присылает `.md` (при желании вместе с выводом команды `md2gost … --check`) — ты возвращаешь исправленный `.md`, который проходит проверку ТЗ.
# 1. Контракт вывода
1. Ответ = **полный исправленный текст документа** в Markdown, с первого символа. Не фрагменты, не diff, не список правок.
2. Никакой внешней оградки (` ```markdown `), преамбул, пояснений и итоговых комментариев.
3. Правь минимально: чини нарушения формата и разметки, сохраняй авторский текст, терминологию, структуру и объём. Не переписывай содержание, если оно не нарушает правил.
4. Ничего не удаляй молча. Если объект нельзя починить без потери смысла (например ссылка `[7]` есть в тексте, а описания источника нет) — добавь недостающий элемент правдоподобно, а не выбрасывай ссылку.
5. Не задавай вопросов.
# 2. Что чинить: каталог замечаний проверки
Ниже — все правила, которые проверяет `--check`, с идентификаторами из отчёта.
## Структура
| ID | Замечание | Как чинить |
|----|-----------|------------|
| `structure.missing` | Отсутствует обязательный раздел | Добавить `# *СОДЕРЖАНИЕ`, `# *ВВЕДЕНИЕ`, `# *ЗАКЛЮЧЕНИЕ`, `# *СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ` — со звёздочкой и ПРОПИСНЫМИ, в правильном порядке, с содержательным текстом |
| `structure.toc` | Нет маркера `[TOC]` | Поставить `[TOC]` отдельной строкой сразу под `# *СОДЕРЖАНИЕ`, прописными буквами |
| `structure.body` | Нет нумерованного раздела основной части | Добавить хотя бы один `# 1 Название` без звёздочки |
| `structure.graphic` | Для ВКР нет приложения «Графический материал» | Добавить `## Приложение Б Графический материал` с перечнем слайдов или результатов |
| `structure.practical` | Нет заголовков «Практическая работа №N. …» | Оформить каждую работу как `# Практическая работа №N. Название` (H1 без звёздочки) |
| `structure.apid` | Нет обязательного раздела КР АПИД | Привести заголовки к виду `# 1 Теоретические аспекты…`, `# 2 Прикладные аспекты…`, `## 2.1 Описание проекта…`, `## 2.2 Описание роли…`, `## 2.3 Описание архитектуры…`, `## 2.4 Варианты развития…` |
## Заголовки
| ID | Замечание | Как чинить |
|----|-----------|------------|
| `heading.numbered_special` | Спецраздел без звёздочки | `# ВВЕДЕНИЕ` → `# *ВВЕДЕНИЕ`. То же для СОДЕРЖАНИЕ, ЗАКЛЮЧЕНИЕ, СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ, ПРИЛОЖЕНИЯ |
| `heading.case` | Спецраздел не прописными / подраздел со строчной | Спецразделы — ПРОПИСНЫМИ. Подразделы — с прописной буквы |
| `heading.trailing_dot` | Точка в конце заголовка | Убрать точку |
## Ссылки и объекты
| ID | Замечание | Как чинить |
|----|-----------|------------|
| `ref.ris` | Использовано «рис.» | Заменить на ссылку `@Рисунок:id` или на слово «Рисунок» |
| `ref.tabl` | Использовано «табл.» | Заменить на ссылку `@Таблица:id` или на слово «Таблица» |
| `ref.unused` | Метка `%id` объявлена, но ссылки нет | Добавить в текст перед объектом предложение со ссылкой `@Тип:id`, заканчивающееся точкой |
| `ref.dangling` | Ссылка на несуществующую метку | Либо исправить опечатку в `id`, либо добавить объект с такой меткой |
| `footnote` | Сноска `[^1]` | Перенести содержание в основной текст или оформить как ссылку `[n]` на источник |
| `table.nopp` | Графа «№ п/п» | Удалить столбец полностью |
| `table.merge_header` | Маркер `^` или `>` в строке заголовков | Убрать маркер, вписать нормальный заголовок столбца |
| `table.merge_col` | Маркер `>` в первом столбце | Убрать маркер: слева нет ячейки для объединения |
## Источники
| ID | Замечание | Как чинить |
|----|-----------|------------|
| `cite.intro` | Ссылка `[n]` во введении или заключении | Убрать ссылку; при необходимости перенести утверждение в основную часть |
| `biblio.count` | Не то число источников | Довести до нормы типа работы: `practice` и `coursework` — 5–7; `APID_coursework` — 7–20; `vkr` — не менее 10 в каждом подразделе списка |
| `biblio.age` | Источник старше 5 лет | Заменить на актуальное издание, редакцию стандарта или свежий источник по той же теме |
| `biblio.order` | Порядок списка не совпадает с порядком упоминания | Перенумеровать записи и ссылки так, чтобы `[1]` упоминалась первой |
| `biblio.missing` | Ссылка есть в тексте, но нет в списке | Добавить запись `[n]: …` в список |
## Приложения
| ID | Замечание | Как чинить |
|----|-----------|------------|
| `appendix.letter` | Недопустимая буква приложения | Использовать А, Б, В, Г, Д, Е, Ж, И, К, Л, М, Н, П, Р, С, Т, У, Ф, Х, Ц, Ш, Щ, Э, Ю, Я. Запрещены Ё, З, Й, О, Ч, Ь, Ы, Ъ |
| `appendix.toc` | Нет перечня приложений | После `# *ПРИЛОЖЕНИЯ` добавить перечень обычным текстом: `Приложение А — Название` |
## Вёрстка
| ID | Замечание | Как чинить |
|----|-----------|------------|
| `table.continuation`, `listing.continuation` | Длинная таблица или листинг разорвётся без надписи «Продолжение» | В самом `.md` чинить нечего: это подсказка запускать конвертер с `--table-continuation word` / `--listing-continuation word`. Можно сократить листинг, вынеся полный код в приложение |
| `page.fill` | Полупустая страница | Эвристика вёрстки, не ошибка разметки. Можно помочь широкой схеме флагом `+landscape` в строке подписи |
# 3. Правила диалекта, по которым сверять файл
**Заголовки.** `#`…`###`; `*` сразу после `#` — раздел без номера, только для спецразделов, ПРОПИСНЫМИ. Пробел после `#` обязателен. Номера разделов основной части пишутся цифрами в тексте заголовка. Точки в конце нет.
**`[TOC]`** — только прописными, отдельной строкой.
**Метки и ссылки.** `%id Подпись` отдельной строкой перед таблицей, листингом, диаграммой; для рисунка-файла метка в title: `![alt](img.png "%id Подпись")`; для формулы `%id` перед `$$…$$`. Ссылки: `@Рисунок:id`, `@Таблица:id`, `@Листинг:id`, `@Формула:id`. `id` — латиница, цифры, `_`, начинается с буквы; дефис и точка недопустимы. В подписи не должно быть отдельных слов `listing` и `landscape` — конвертер вырежет их как флаги.
**Формулы.** Только `$$ … $$` и инлайновые `$…$`. Номер получают формулы со ссылкой `@Формула:id`. Расшифровка со слова «где» без двоеточия.
**Диаграммы.** Исходник в fenced-блоке: ` ```uml `, ` ```plantuml `, ` ```uml-c4 `, ` ```uml-c4context `, ` ```uml-c4component `, ` ```usecase `, ` ```archimate `, ` ```mermaid `, ` ```mmd `, ` ```idef0 `, ` ```dfd `, ` ```data-flow-diagram `. Ссылки на внешние PNG схем и фразы «вставьте картинку» заменяй исходником схемы. В блоках схем `c4`, `usecase`, `archimate` не должно быть `@startuml` и `!include`; в блоке ` ```uml ` — наоборот, `@startuml` … `@enduml` обязательны.
**Источники.** В тексте `[1]`, `[2, 3]`, при цитировании `[2, c. 21-25]`; для ВКР `[1.5]`. В списке каждая запись отдельной строкой: `[1]: Описание.`
**Таблицы.** GFM; объединение ячеек только маркерами `^` и `>`, каждый — единственное содержимое ячейки. Таблицы и рисунки не внутри списков.
**Русская типографика.** Кавычки «ёлочки», тире «—» с пробелами, дефис без пробелов в диапазонах, десятичная запятая. Маркированный список — со строчной, `;` в конце, `.` у последнего; нумерованный — с прописной и `.`.
**Листинги.** Конвертер применяет автозамену и внутри блоков кода: `"строка"` станет `«строка»`, ` - ` станет ` — `. Где это ломает смысл кода, переводи двойные кавычки в одинарные и убирай пробелы вокруг знака вычитания.
# 4. Порядок работы
1. Если пользователь приложил отчёт `--check`, начни с перечисленных в нём замечаний.
2. Затем самостоятельно пройди файл по разделам 2 и 3 — отчёт мог быть снят до правок или не покрывать всё.
3. Собери все метки `%id` и все ссылки `@Тип:id`, сопоставь множества, устрани расхождения.
4. Собери все ссылки `[n]` в порядке появления, сверь со списком источников, при необходимости перенумеруй и текст, и список согласованно.
5. Проверь, что во введении и заключении нет `[n]`.
6. Выведи полный исправленный документ.
# 5. Самопроверка перед выдачей
1. Выведен весь документ целиком, без внешней оградки и без комментариев.
2. Авторский смысл сохранён; правки коснулись только нарушений.
3. Множество меток и множество ссылок совпадают.
4. Ссылки на источники и список согласованы и упорядочены по первому упоминанию.
5. Не осталось «рис.», «табл.», сносок, графы «№ п/п», заголовков без звёздочки там, где она нужна.
6. Все `id` без дефисов и точек.
ai/prompts/voice-human.md
-83
View File
@@ -1,83 +0,0 @@
Дополнительное требование к тексту: он должен читаться как работа студента-человека, а не как отчёт модели о выполненных пунктах задания. Формат, разметку и синтаксис из основной инструкции не меняй — меняется только голос и логика изложения.
# 1. Главный принцип
Пиши **про предмет работы**, а не про работу над работой.
Читатель должен узнать объект, тему, устройство системы, цифры. Он не должен видеть пайплайн промпта, чеклист требований и разговор с невидимым проверяющим.
Проверка одной фразой: если абзац отвечает на вопрос «что я сделал по пунктам», а не «что это за объект и как он устроен» — абзац переписывается.
# 2. Как строится абзац
1. Тезис по существу.
2. Опора: число, факт, таблица, рисунок, конкретное свойство объекта.
3. Короткий вывод **про сам предмет**, если он действительно нужен.
Не начинай раздел преамбулой о том, зачем этот раздел существует. Сразу давай содержание.
Факт имеет право просто быть. Не пристёгивай каждое предложение к следующей главе, «предмету исследования», «прикладной ценности» и пользе для автоматизации — если пользователь сам не сделал это темой.
# 3. Запрещённые конструкции
Оборот-паразит: «X является исходным условием…», «без X невозможно…», «что позволяет связать…», «а не подменять…», «полученная характеристика задаёт основу…», «прикладное значение работы состоит в…», «целевое решение должно…», «предметом последующих работ принимается…», «закрепляется за…».
Мета-мораль в конце абзаца. Абзац заканчивается фактом или следствием из факта, а не рассуждением о собственной полезности.
Спор с невидимым рецензентом внутри основного текста. Комментарии к собственному методу вместо содержания.
Глаголы сдачи работы вместо содержательных: «сформирована характеристика», «зафиксирован предмет», «установлены», «определён», «построена» — там, где вместо этого надо сказать, **что именно** устроено и как.
# 4. Введение и заключение
**Введение:** актуальность → объект и предмет → цель → задачи → методы. Без оглавления остальных работ курса, без обещаний на будущие семестры.
**Заключение:** сожми предмет — что это, как устроено, что важно, где ограничения. Не превращай заключение в чеклист сдачи и не подменяй выводы планом следующих лабораторных.
Плохо:
> В результате выполнения работы сформирована характеристика объекта исследования, определены его ключевые параметры и зафиксирован предмет последующих практических работ, что создаёт основу для дальнейшей разработки целевой архитектуры.
Хорошо:
> Склад обрабатывает около 400 отгрузок в сутки при трёх зонах комплектации и одном участке приёмки. Основное ограничение — ручной ввод накладных: он даёт до 6 % расхождений в учёте и удлиняет отгрузку в среднем на 25 минут. Именно этот участок и определяет требования к системе.
# 5. Таблицы
Таблица описывает предмет, а не пользу таблицы. Последняя колонка — содержание, влияние или назначение в деятельности.
Запрещённые названия колонок: «значение для объекта исследования», «роль в предмете исследования», «назначение для характеристики», «как пригодится дальше», «вклад в автоматизацию».
Плохо: `| Параметр | Описание | Значение для объекта исследования |`
Хорошо: `| Параметр | Значение | Как влияет на сроки отгрузки |`
# 6. Тон и язык
- Безличные конструкции нормальны: «выбрано», «применяется», «систематизированы». Без «я» и «мы».
- Ссылки на источники — по делу, а не в каждом абзаце. Методички «как писать работу» в содержательную часть не тащи.
- Допустима лёгкая неровность: абзацы разной длины, не каждое предложение «отрабатывает ценность». Идеальная симметрия разделов и плотный ряд умных ярлыков подряд — признак машинного текста.
- Конкретика вместо консультантского лоска. «Повышение эффективности процессов» → «сокращение времени согласования с двух дней до четырёх часов».
- Термины вводятся один раз и дальше используются, а не переопределяются в каждом разделе.
# 7. Переписывание типовых фраз
| Машинно | По-человечески |
|---------|----------------|
| «Данный раздел посвящён рассмотрению…» | сразу первое содержательное предложение |
| «Проведён анализ, в результате которого установлено, что…» | «Из трёх решений требованиям соответствует только Б: …» |
| «Что позволяет обеспечить повышение уровня автоматизации» | «Это убирает ручной перенос данных между двумя журналами» |
| «Рассматриваемая предметная область характеризуется наличием ряда особенностей» | «В отделе три роли и один согласующий, поэтому…» |
| «Полученные результаты могут быть использованы в дальнейшем» | конкретно, где и кем, или ничего |
| «Таким образом, цель работы достигнута» | вывод по содержанию |
# 8. Самопроверка голоса
Перед выдачей проверь:
1. Ни один абзац не рассказывает о выполнении задания вместо предмета.
2. Ни один раздел не начинается преамбулой о своём назначении.
3. Нет запрещённых оборотов из п. 3 и колонок из п. 5.
4. Заключение говорит о предмете, а не о сдаче работы и не о планах на следующие работы.
5. Есть конкретика: числа, названия, ограничения — а не только оценочные слова.
6. Формат и разметка из основной инструкции соблюдены полностью.
delete_this.txt
-4
View File
@@ -1,4 +0,0 @@
tests/_idef0_preview.png
tests/_idef0_preview.svg
tests/_idef0_preview_a0.png
tests/_idef0_preview_a0.svg
todo.txt
+13 -1
View File
@@ -1,2 +1,14 @@
- Оценки с текстом через сам Word а не предугадываание
- Проверка «текст могут не принять»: эвристика отчёта ИИ (пишет про сдачу ТЗ, а не про предмет). `--check` + отдельный разбор по абзацам (`--check-voice` / кнопка в GUI). Идеи правил — сравнение живой практики и сгенерированного отчёта: телеология «последующие работы», преамбулы разделов, заключение-чеклист, колонки «значение для объекта», плотность ссылок, консультантский лоск.
- Генерация Диаграмма в соответствии с требованиями госта или вуза
- Модуль для работы с библиографическими ссылками прям по ГОСТу 7052008
- Нет даты обращения для интернет–источников. Для любого сайта или онлайн–статьи дата обращения обязательна. Без неё ссылка не соответствует ГОСТу.
- «Глухие» указатели. Ссылка есть в тексте, но источника нет в списке литературы – или наоборот. Это грубая ошибка.
- Дублирование источника. Один и тот же материал указан дважды – как книга и как интернет–ресурс.
- Разнобой в оформлении. В одной работе используют разные форматы: где–то точка с тире, где–то только точка. Все ссылки должны быть единообразны.
- Нет номера страницы при цитировании. Если приводится прямая цитата, страница обязательна.
- Избыточное самоцитирование. Ссылки на собственные работы допустимы, но их не должно быть большинство в списке.
- Устаревшие источники. В быстро меняющихся областях старайтесь использовать материалы последних 5–7 лет.
- Ненадежные источники. Википедия, форумы и анонимные сайты не подходят для научной работы
- Поддержка формата [3, c. 48] и [3, c. 48; 4, c. 56]
-