v0.5.2

Что то сделал
2026-09-08 19:37:54 +03:00
parent 1a5b35eb54
commit 510f7e7adf
90 changed files with 11720 additions and 5547 deletions
@@ -6,11 +6,14 @@

 1. [Быстрый старт](quickstart.md) — установка, первое окно, exe
 2. [Синтаксис Markdown](markdown.md) — чем диалект отличается от обычного MD
-3. [Схемы и диаграммы](schemes.md) — UML, Mermaid, настраиваемые схемы
-4. [Типы документов](types.md) — coursework, practice, vkr, PIS_custom, APID_coursework
-5. [CLI и GUI](cli-gui.md) — флаги и соответствие в интерфейсе
-6. [Кастомные стили (JSON)](styles.md) — оверлей полей и стилей абзацев
-7. [Промпты для ИИ](prompts.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/).

@@ -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`).
@@ -8,7 +8,9 @@
 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`.
@@ -24,6 +26,10 @@ python -m md2gost report.docx --check-pages   # только проверка в
 | `--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` |
@@ -34,6 +40,7 @@ python -m md2gost report.docx --check-pages   # только проверка в
 | `--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) |
@@ -47,14 +54,31 @@ DOCX не умеет сам писать «Продолжение Таблицы
 ## Меню GUI

 - **Настройки → Файлы** — шаблон, титул, задание, стили JSON, выходной путь
- **Настройки → Диаграммы** — PlantUML, Mermaid (Chromium), Kroki, формат, кэш includes
+- **Настройки → Студент…** — ФИО и группа (при первом запуске спрашивают сами)
+- **Настройки → Метаданные…** — свойства 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`.
@@ -89,7 +89,7 @@ def f():

 ## Диаграмма → Рисунок

-Перед блоком — `%id Подпись`. Языки: `uml`, `plantuml`, `mermaid`/`mmd`, или id схемы (`c4`, `bpmn`, …).
+Перед блоком — `%id Подпись`. Языки: `uml`, `plantuml`, `mermaid`/`mmd`, `idef0`, `dfd`/`data-flow-diagram` (Graphviz вшитый/PATH или Kroki), или id схемы (`c4`, `usecase`, …).

 - `+listing` — ещё и Листинг с исходником
 - `+landscape` — альбомная страница под широкий рисунок/таблицу
@@ -144,6 +144,12 @@ $$
 - Тире в предложениях: «—» (по умолчанию сохраняется). Замена на «-»: `--emdash-to-hyphen`.
 - Строка `---` / `***` / `___` по умолчанию **игнорируется**. Разрыв страницы: `--hr-pagebreak` или галочка в GUI.

+## Автотитульник (метаданные в MD)
+
+В начале файла можно указать блок с оградой `title` (номер работы, год, оверрайды полей). Рядом с файлом — `info_conv.yaml` с институтом, кафедрой, дисциплиной и преподавателем. ФИО и группа студента задаются в GUI / CLI, не в yaml. Автогенерация титула **по умолчанию выкл.** — включите `--auto-title` или галочку «Автотитул».
+
+Подробно: [title.md](title.md).
+
 ## Запрещено в отчёте

 - «рис.», «табл.»
@@ -9,11 +9,12 @@
 | [`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).
-2. В GUI включите нужные схемы (C4, BPMN, …) — в конец промпта добавятся макросы и `ai-prompt` из `md2gost.schemes.json`.
+1. Откройте промпт (файл или GUI). При необходимости добавьте `emulate-student` после базового generate-*.
+2. В GUI включите нужные схемы (C4, usecase, …) — в конец промпта добавятся макросы и `ai-prompt` из `md2gost.schemes.json`.
 3. Скопируйте собранный текст в ChatGPT / Claude / Cursor / Copilot.
 4. Следующим сообщением: тип работы, тема, черновик / требования.
 5. Сохраните ответ как `.md` и конвертируйте:
@@ -24,7 +25,7 @@ python -m md2gost report.md -o report.docx --type coursework --check --strict

 ## Зачем кнопки схем

-Базовый промпт уже говорит: блоки `` ```uml `` / `` ```mermaid `` / `` ```uml-c4 `` конвертер сам превратит в Рисунок. Кнопки нужны, когда модели надо знать **конкретные макросы** выбранной схемы (Person/Rel для C4, Start/XOR/Flow для BPMN и т.д.) — в том числе пользовательских из «Шаблоны UML».
+Базовый промпт уже говорит: блоки `` ```uml `` / `` ```mermaid `` / `` ```uml-c4 `` конвертер сам превратит в Рисунок. Кнопки нужны, когда модели надо знать **конкретные макросы** выбранной схемы (Person/Rel для C4, actor/usecase и т.д.) — в том числе пользовательских из «Шаблоны UML».

 ## Подробнее о синтаксисе

@@ -38,11 +38,13 @@ md2gost-gui                    # то же GUI (entry point)

 1. Перетащите `.md` в верхнюю область (или кликните по ней).
 2. Выберите тип документа (`practice` по умолчанию).
-3. При необходимости: Настройки → Файлы (титул, задание), Настройки → Диаграммы, меню «Шаблоны UML».
+3. При необходимости: Настройки → Файлы (титул, задание), **Настройки → Студент…** (ФИО и группа для автотитула), **Настройки → Метаданные…** (свойства DOCX), Настройки → Диаграммы, меню «Шаблоны UML».
 4. Нажмите «Конвертировать».

 Справка в меню: **Инструкция**, **Схемы**, **Промпт для ИИ**.

+Автотитул (`info_conv.yaml` + блок `title`): [title.md](title.md).
+
 ## Типы документов (кратко)

 | `--type` | Назначение |
@@ -57,5 +59,6 @@ md2gost-gui                    # то же GUI (entry point)
 ## Следующие шаги

 - Написать отчёт в диалекте md2gost: [markdown.md](markdown.md)
+- Автотитульник: [title.md](title.md)
 - Вставить диаграммы: [schemes.md](schemes.md)
 - Сгенерировать `.md` через ИИ: [prompts.md](prompts.md)
@@ -1,6 +1,6 @@
 # Схемы и диаграммы

-В отчёте блок кода с языком диаграммы превращается в **Рисунок** (PNG или SVG). PNG руками экспортировать не нужно: md2gost вызывает PlantUML (jar / Kroki) или локальный Mermaid (браузер / QuickJS), иначе Kroki.
+В отчёте блок кода с языком диаграммы превращается в **Рисунок** (PNG или SVG). PNG руками экспортировать не нужно: md2gost вызывает PlantUML (jar / Kroki), локальный Mermaid (браузер / QuickJS), локальный IDEF0 (Pillow) или DFD через [data-flow-diagram](https://github.com/pbauermeister/dfd) (вшитый / системный Graphviz или Kroki).

 ## Синтаксис в markdown

@@ -32,13 +32,12 @@ Rel(user, app, "логин")
 | `` ```uml `` / `` ```plantuml `` | Сырой PlantUML (`@startuml`…`@enduml`) |
 | `` ```uml-<id> `` / `` ```<id> `` | Схема из `md2gost.schemes.json` (обёртка и `!include` добавляются сами) |
 | `` ```mermaid `` / `` ```mmd `` | Mermaid: браузер / QuickJS / Kroki |
-| `` ```bpmn `` / `` ```uml-bpmn `` | BPMN 2.0 (макросы библиотеки md2gost) |
-
-**IDEF0 / DFD** конвертер не рисует — вставляйте готовый PNG как обычный Рисунок.
+| `` ```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` рядом с приложением (существующий файл не перезаписывается).
+Файл шаблона: [`md2gost/diagrams/schemes.json`](../md2gost/diagrams/schemes.json). При первом запуске копируется в `md2gost.schemes.json` рядом с приложением. При каждом запуске встроенные схемы (`author: md2gost`) синхронизируются с шаблоном: новые id добавляются, устаревшие (например удалённый `bpmn`) убираются, содержимое обновляется. Схемы с пустым или другим `author` не трогаются. Если правите встроенную в GUI и сохраняете — `author` сбрасывается, чтобы миграция не затёрла правки.

 | id | Название | Оградка |
 |----|----------|---------|
@@ -46,9 +45,9 @@ Rel(user, app, "логин")
 | `c4context` | C4 Context | `` ```uml-c4context `` |
 | `c4component` | C4 Component | `` ```uml-c4component `` |
 | `usecase` | Прецеденты | `` ```uml-usecase `` / `` ```usecase `` |
-| `bpmn` | BPMN 2.0 | `` ```bpmn `` / `` ```uml-bpmn `` |
+| `archimate` | ArchiMate 3.2 | `` ```uml-archimate `` / `` ```archimate `` |

-Для схем в теле пишите **только макросы** (Person, Start, XOR, …) — без `@startuml` и без `!include`, если схема сама их добавляет.
+Для схем в теле пишите **только макросы** (Person, Rel, actor, Business_Actor, …) — без `@startuml` и без `!include`, если схема сама их добавляет.

 ### C4 (пример макросов)

@@ -58,14 +57,151 @@ Rel(user, app, "логин")

 `actor`, `usecase`, связи `-->`, `<<include>>`, `<<extend>>`.

-### BPMN
+### ArchiMate 3.2

-`Pool` / `Lane`, `Start` / `StartMessage` / `End`, `UserTask` / `ServiceTask`, `XOR` / `AND` / `OR`, `Flow` / `CondFlow` / `DefaultFlow` / `MessageFlow`, …
-
-Sequence Flow только внутри пула; между пулами — `MessageFlow`.
+`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
@@ -114,7 +250,15 @@ id схемы: латиница, цифры, `_`; начинается с бук
 3. QuickJS + mermaid.js (`mermaidx`) — офлайн без браузера
 4. Локальный Kroki → `https://kroki.io` (если `--diagram-fallback remote`)

-Формат: `--diagram-format png` (по умолчанию) или `svg`. Масштаб растра PlantUML / локального Mermaid: `--diagram-scale` (по умолчанию 2 — качество, размер на странице как при 1).
+**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).
@@ -124,3 +268,5 @@ id схемы: латиница, цифры, `_`; начинается с бук
 1. Меню **Шаблоны UML** — добавить / править / сохранить.
 2. Или править `md2gost.schemes.json` вручную («Открыть JSON»).
 3. CLI: `--schemes путь.json`.
+
+Чтобы правка встроенной схемы не сбрасывалась при обновлении приложения, оставьте пустой `author` (GUI делает это сама при сохранении изменённой встроенной схемы).
@@ -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` рядом с приложением (см. каталог схем). Не коммитьте его с чужими ФИО в общие репозитории отчётов — это локальные данные студента.
@@ -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`.