v0.5.4

NewPromt
- small fix

AIV2/context/academic-style.md

@@ -0,0 +1,115 @@
+# Собственно-научный стиль отчёта по практикам
+
+Справочник для модели: как писать текст отчёта, чтобы он проходил проверку преподавателя по содержанию, а не только `--check` по разметке. Извлечено из типовых замечаний к отчётам ПАЦО / проектным практикам.
+
+---
+
+## 1. Подстиль
+
+Текст отчёта — **собственно-научный подстиль** русского научного стиля (как в отчёте о НИР, ГОСТ 7.32). Это не публицистика, не консультантский слайд и не набор тезисов.
+
+Допустимо: безличные конструкции, термины, факты, ссылки, причинно-следственные формулировки («обусловлено», «определяется», «характеризуется»).
+
+Недопустимо:
+
+| Запрещённый приём | Пример | Как заменить |
+|-------------------|--------|--------------|
+| Метафора и давление | «ручная проверка давит на маржу» | «трудоёмкость ручной проверки комплектов увеличивает операционные издержки» |
+| Разговорный вектор | «социальные факторы тянут к…» | «в социальной среде наблюдается спрос на…» |
+| Лозунг с “зато” | «платформа усложняется, зато сведения можно сверять автоматически» | «развитие программных интерфейсов реестров создаёт возможность автоматической сверки сведений» |
+| Живая разговорность | «экосистема растёт», «общество тянет массу группы», «нет смысла в отделе» | нейтральная констатация факта |
+| Тезисная рубка | «Экономические факторы — спрос. Социальные — Госключ. Технологические — облако.» | связные абзацы, каждый фактор раскрыт предложением |
+| Мета про сдачу | «сформирована характеристика объекта» | содержание объекта, а не факт выполнения пункта |
+
+Проверка абзаца: его можно поставить в отчёт о НИР без ощущения статьи или презентации. Если нет — переписать.
+
+«Живой голос» из `voice-human.md` означает конкретику и отсутствие мета-чеклиста модели. Он **не** означает публицистические глаголы и антитезы.
+
+---
+
+## 2. Заголовки пунктов практики
+
+Если задание называет пункт «Характеристика объекта исследования» — заголовок раздела:
+
+```markdown
+# 1 Характеристика объекта исследования
+```
+
+**Нельзя** писать `# Практическая работа 1 …` и `# Практическая работа №1. …`, если руководитель прямо потребовал убрать слова «Практическая работа» из названия пункта.
+
+Профиль `PIS_custom` в `--check` как раз требует «Практическая работа №N. …». Для отчётов ПАЦО с нумерованными пунктами задания собирай документ как `--type practice` (или `coursework`), а не `PIS_custom`.
+
+---
+
+## 3. Подпункты
+
+Не дроби один пункт задания на искусственные `##` («Юридический статус», «Специфика», «Организационная модель» и т. п.), если преподаватель запретил лишние подразделы.
+
+Один пункт задания = один H1 (или один нумерованный раздел). Смена темы внутри пункта — новый абзац, а не новый заголовок. Рисунок и таблица сами членят текст.
+
+Подразделы `##` оставляй только если их явно требует бланк задания или профиль `--check` (цель / ход / выводы в `PIS_custom`; фиксированные `## 2.1` в АПИД).
+
+---
+
+## 4. Полное наименование, затем сокращение
+
+При **первом** появлении в тексте:
+
+1. полное официальное наименование;
+2. затем сокращение или аббревиатура в скобках, при необходимости с «далее —».
+
+```text
+Акционерное общество «Производственная фирма «СКБ Контур» (далее — АО «ПФ «СКБ Контур») является акционерным обществом частной формы собственности…
+электронный документооборот (ЭДО)
+удостоверяющий центр (УЦ)
+машиночитаемая доверенность (МЧД)
+```
+
+Дальше по тексту — только принятое сокращение. Не начинай документ с аббревиатуры, которую ещё не ввели. Не вводи одно и то же сокращение дважды.
+
+---
+
+## 5. Таблица реквизитов
+
+Реквизиты юридического лица (наименование, ИНН, ОГРН, адрес, директор, капитал) **не оформлять таблицей «Реквизит / Значение»**. Значимые сведения из такой таблицы переносятся в связный абзац.
+
+Таблицу оставляй там, где сравниваются однородные ряды: коды ОКВЭД, динамика показателей по годам, сопоставление конкурентов. Таблица из одной строки данных не нужна.
+
+---
+
+## 6. Ссылки на источники
+
+Несколько источников на одно утверждение — **одной скобкой**:
+
+| Нельзя | Надо |
+|--------|------|
+| `[1], [2]` | `[1, 2]` |
+| `[2], [5]` | `[2, 5]` |
+| `[1], [2], [5]` | `[1, 2, 5]` |
+| `[6], [7]` | `[6, 7]` |
+
+Одиночная ссылка `[1]` допустима. Форма с страницами: `[2, c. 21-25]`. Во введении и заключении ссылок нет.
+
+---
+
+## 7. Границы пункта задания
+
+Факт относится к тому пункту, которому он принадлежит.
+
+- Характеристика **объекта**: статус, виды деятельности, оргмодель, карта верхнего уровня, макро- и микросреда, масштаб.
+- Нельзя в характеристике объекта разворачивать узкое место процесса, параметры оптимизации, «рост заявок упирается в ручную проверку» — это пункт про предмет / процесс (практика 2 и далее).
+- В пункте про процесс не повторять заново всю справку об объекте.
+
+---
+
+## 8. Критический разбор до сдачи
+
+На текущем принятом этапе достаточно формальной комплектности. **В последующих практиках** студент до загрузки файла сам разбирает представляемый фрагмент проектного решения:
+
+1. Все ли обязательные артефакты пункта на месте и читаемы.
+2. Согласованы ли объект, оргмодель, карта и текст процесса.
+3. Нет ли публицистики, лишних подразделов, таблиц-дублей текста.
+4. Выдержана ли иерархия на оргсхеме (см. `org-hierarchy.md`).
+5. Не попал ли материал не в свой пункт.
+
+Модель, которая готовит следующую практику, проводит этот разбор молча и правит текст **до** выдачи файла. Не вставляй в отчёт фразу «проведён критический анализ».

AIV2/context/archimate.md

@@ -0,0 +1,514 @@
+# 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` на одной схеме нельзя.

AIV2/context/checker.md

@@ -0,0 +1,165 @@
+# Проверка ТЗ — полный каталог замечаний
+
+Что именно проверяет `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`, факты — вычиткой.

AIV2/context/cli.md

@@ -0,0 +1,242 @@
+# Запуск, профили и настройки 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 рисуется локально без внешних зависимостей.

AIV2/context/diagrams.md

@@ -0,0 +1,587 @@
+# Диаграммы в 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. Иерархическая оргсхема и читаемость
+
+Рисунок, который нельзя прочитать при масштабе 100 % в Word, при проверке равен отсутствию рисунка. Широкие схемы помечай `+landscape`. Кегль подписей после вставки на лист — не меньше 10–11 пт. Если встроенный PlantUML или Mermaid даёт мелкую схему, сдавай PNG высокого разрешения.
+
+На оргмодели из одного узла выходит **одна** связь, затем развязка на подчинённых (горизонтальная шина). Пачка независимых линий `ceo -- a`, `ceo -- b`, `ceo -- c` — ошибка. Стрелки не используются.
+
+У каждого показанного отдела есть руководитель и специалисты операционного уровня. Нельзя оставлять бокс направления с одним специалистом или без людей. Должности обезличены.
+
+Каркас развязки:
+
+```text
+            [Родитель]
+                 |
+        ---------+---------
+        |        |        |
+     [Доч.1]  [Доч.2]  [Доч.3]
+```
+
+Карта процессов верхнего уровня — группы без стрелок последовательности.
+
+## 10. Свои схемы
+
+Файл `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`.

AIV2/context/org-hierarchy.md

@@ -0,0 +1,93 @@
+# Иерархические схемы в отчёте
+
+Правила организационной модели и карты процессов верхнего уровня. Нарушение приравнивается преподавателем к отсутствию рисунка или к неверной модели.
+
+---
+
+## 1. Читаемость = наличие рисунка
+
+Рисунок, который нельзя разобрать при масштабе 100 % в Word (и который не читается даже при увеличении), **считается отсутствующим**.
+
+Обязательно:
+
+- крупный кегль подписей: на листе после вставки в DOCX не меньше 10–11 пт;
+- флаг `+landscape` для широких схем;
+- не более одной мысли на бокс, без «простыни» из 8-пунктового текста;
+- чёрные линии на белом, без декоративной заливки, мешающей печати;
+- если встроенный PlantUML/Mermaid после сборки даёт мелкую кашу — вынести схему в отдельный PNG высокого разрешения (`figsize` 14–18 дюймов по ширине, DPI ≥ 200) и вставить как `![…](figures/….png "%id Подпись +landscape")`.
+
+Нельзя сдавать схему, которую «можно рассмотреть, если открыть исходник». Проверяют PDF/DOCX.
+
+---
+
+## 2. Принцип развязки коннектора
+
+На иерархической оргсхеме **из одного узла выходит одна связь**, которая затем разветвляется на подчинённых (горизонтальная шина / Т-образный коннектор).
+
+Неправильно: от «Генеральный директор» independently идут 6–8 отдельных линий к каждому департаменту.
+
+Правильно:
+
+```text
+            [Родитель]
+                 |
+        ---------+---------     ← одна развязка
+        |        |        |
+     [Доч.1]  [Доч.2]  [Доч.3]
+```
+
+В matplotlib / ручной отрисовке: вертикаль вниз от родителя → горизонталь по центрам детей → вертикали в каждый ребёнок.
+
+В PlantUML не писать пачку `ceo -- a`, `ceo -- b`, `ceo -- c` без общей шины. Либо скрытый стыковочный узел, либо заранее собранный PNG с развязкой.
+
+Стрелки на оргмодели не нужны: связь иерархическая, не поток.
+
+---
+
+## 3. Полнота подразделения
+
+Если на схеме есть **отдел / департамент / направление**, у него изображаются:
+
+1. руководитель (начальник отдела, руководитель направления, директор по функции);
+2. специалисты операционного уровня.
+
+Нельзя оставлять бокс «Отдел выпуска» с одним «специалистом» и без начальника. Нельзя оставлять бокс направления без людей: пустое имя подразделения приравнивается к неполной структуре.
+
+Типовые наименования брать из справочника должностей, не выдумывать креатив. Фамилии не писать — только должности.
+
+Детализация:
+
+- подразделение, где сидят исполнители выбранного процесса, — до начальников участков и операционных специалистов;
+- прочие направления — типовой минимум: руководитель + специалист;
+- элементы, которые не понадобятся процессу, на схему не выносить, но то, что вынесено, должно быть полным.
+
+---
+
+## 4. Карта процессов верхнего уровня
+
+- Группы процессов (основные, обеспечивающие, развития; управление — только если этого требует задание).
+- Внутри группы — наименования направлений, не клики и не технология выполнения.
+- Стрелок последовательности на карте верхнего уровня нет.
+- Предмет последующего исследования можно отметить сноской на элементе, без разбора узкого места: узкое место относится к пункту про процесс.
+
+---
+
+## 5. Каркас иерархии (PNG)
+
+```text
+                    Генеральный директор
+                              |
+         ---------------------+---------------------
+         |          |         |          |         |
+   Рук. направл.  Рук. сети  Рук. направл.  …     Рук. службы
+   (процессное)   СЦ         (типовое)
+         |
+    -----+-----
+    |    |    |
+  Нач. Нач. Нач.
+  участка
+    |
+  Специалист
+```
+
+Подписи — должность и принадлежность («специалист центра регистрации»), не «владелец процесса» и не комментарий для преподавателя.

AIV2/context/syntax.md

@@ -0,0 +1,459 @@
+# Диалект 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], [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 с.
+~~~