@h2nguyen/arc42-node-mcp-server 2.0.0 → 2.1.1

package/dist/templates/locales/ru/templates-asciidoc.js

@@ -0,0 +1,996 @@
+/**
+ * Russian Templates - AsciiDoc Format
+ *
+ * Contains all arc42 section templates in Russian using AsciiDoc syntax.
+ * Based on the official arc42 templates from vendor/arc42-template.
+ *
+ * @module templates/locales/ru/templates-asciidoc
+ */
+/**
+ * Get the Russian AsciiDoc template for a specific section
+ */
+export function getTemplate(section) {
+    const templates = {
+        '01_introduction_and_goals': getIntroductionAndGoalsTemplate,
+        '02_architecture_constraints': getArchitectureConstraintsTemplate,
+        '03_context_and_scope': getContextAndScopeTemplate,
+        '04_solution_strategy': getSolutionStrategyTemplate,
+        '05_building_block_view': getBuildingBlockViewTemplate,
+        '06_runtime_view': getRuntimeViewTemplate,
+        '07_deployment_view': getDeploymentViewTemplate,
+        '08_concepts': getConceptsTemplate,
+        '09_architecture_decisions': getArchitectureDecisionsTemplate,
+        '10_quality_requirements': getQualityRequirementsTemplate,
+        '11_technical_risks': getTechnicalRisksTemplate,
+        '12_glossary': getGlossaryTemplate
+    };
+    return templates[section]();
+}
+function getIntroductionAndGoalsTemplate() {
+    return `= 1. Введение и цели
+
+[role="arc42help"]
+****
+Описывает соответствующие требования и движущие силы, которые должны учитывать архитекторы программного обеспечения и команда разработчиков.
+К ним относятся
+
+* основные бизнес-цели,
+* важные особенности,
+* основные функциональные требования,
+* цели в области качества архитектуры и
+* соответствующие заинтересованные стороны и их ожидания
+****
+
+=== Обзор требований
+
+[role="arc42help"]
+****
+.Содержание
+Краткое описание функциональных требований, движущих сил, выжимка требований. Ссылка на (возможно, уже существующие) документы с требованиями
+(с номером версии и информацией, где ее найти).
+
+.Мотивация
+С точки зрения конечных пользователей система создается или модифицируется, чтобы
+улучшить поддержку деловой активности и/или улучшить качество.
+
+.Форма
+Краткое текстовое описание, вероятно, в табличном формате варианта использования.
+Если существуют документы с требованиями, этот обзор должен ссылаться на эти документы.
+
+Сделайте эти выдержки как можно короче. Соблюдайте баланс читабельности этого документа с потенциальной избыточностью по отношению к документам с требованиями
+
+
+.Дальнейшая информация
+
+Смотрите https://docs.arc42.org/section-1/[Введение и цели] в документации arc42.
+
+****
+
+=== Цели по качеству
+
+[role="arc42help"]
+****
+.Содержание
+Три (максимум пять) главных целей в области качества для архитектуры, выполнение которых имеет первостепенное значение для основных заинтересованных сторон.
+Здесь действительно имеются в виду цели качества для архитектуры. Не путайте их с целями проекта.
+Они необязательно совпадают.
+
+Рассмотрите этот обзор потенциальных тем (на основе стандарта ISO 25010):
+
+image::01_2_iso-25010-topics-EN-2023.drawio.png["Категории требований по качеству"]
+
+.Мотивация
+Вы должны знать цели в области качества наиболее важных заинтересованных сторон, поскольку они будут влиять на фундаментальные архитектурные решения.
+Убедитесь, что вы очень конкретно говорите об этих качествах, избегайте модных словечек.
+Если вы как архитектор не знаете, как будет оцениваться качество вашей работы...
+
+.Форма
+Таблица с целями по качеству и конкретными сценариями, упорядоченными по приоритетам
+****
+
+=== Заинтересованные стороны
+
+[role="arc42help"]
+****
+.Содержание
+Подробный обзор заинтересованных сторон системы, т. е. всех лиц, ролей или организаций, которые
+
+* должны знать архитектуру
+* должны быть уверены в архитектуре
+* работать с архитектурой или с кодом
+* нуждаются в архитектурной документации для своей работы
+* должны принимать решения о системе или ее развитии
+
+.Мотивация
+Вы должны знать все стороны, участвующие в разработке системы или затронутые системой.
+В противном случае вы можете получить неприятные сюрпризы позже в процессе разработки.
+Эти заинтересованные стороны определяют степень и уровень детализации вашей работы и ее результатов.
+
+.Форма
+Таблица именами людей, их ролями и ожиданиями в отношении архитектуры и ее документации.
+****
+
+[options="header",cols="1,2,2"]
+|===
+|Роль/Имя|Контактные данные|Ожидания
+| _<Роль-1>_ | _<Контактные-данные-1>_ | _<Ожидания-1>_
+| _<Роль-2>_ | _<Контактные-данные-2>_ | _<Ожидания-2>_
+|===
+`;
+}
+function getArchitectureConstraintsTemplate() {
+    return `= 2. Архитектурные ограничения
+
+
+[role="arc42help"]
+****
+.Содержание
+Любое требование, ограничивающее архитекторов программного обеспечения в их свободе проектирования и решений по реализации или в принятии решений о процессе разработки. Эти ограничения иногда выходят за рамки отдельных систем и действительны для целых организаций и компаний.
+
+.Мотивация
+Архитекторы должны точно знать, где они свободны в своих проектных решениях, а где должны придерживаться ограничений.
+С ограничениями всегда нужно иметь дело; хотя они могут быть предметом переговоров.
+
+.Форма
+Простые таблицы ограничений с пояснениями.
+При необходимости вы можете разделить их на
+технические ограничения, организационные и политические ограничения и
+соглашения (например, рекомендации по программированию или управлению версиями, документация или соглашения о наименованиях)
+
+
+.Дальнейшая информация
+
+Смотрите https://docs.arc42.org/section-2/[Архитектурные ограничения] в документации arc42.
+
+****
+`;
+}
+function getContextAndScopeTemplate() {
+    return `= 3. Контекст и рамки
+
+
+[role="arc42help"]
+****
+.Содержание
+
+Контекст и область действия — как следует из названия — разграничивают вашу систему (ее рамки) от всех партнеров с которыми она коммуницирует (соседние системы и пользователи, т.е. контекст вашей системы). Таким образом, он определяет внешние интерфейсы.
+
+При необходимости различайте бизнес-контекст (специфические для предметной области входы и выходы) и технический контекст (каналы, протоколы, аппаратное обеспечение).
+
+.Мотивация
+Интерфейсы домена и технические интерфейсы для коммуникационных партнеров являются одними из наиболее важных аспектов вашей системы. Убедитесь, что вы их полностью понимаете.
+
+.Форма
+Различные варианты:
+
+* Контекстные диаграммы
+* Списки коммуникационных партнеров и их интерфейсов.
+
+.Дальнейшая информация
+
+Смотрите https://docs.arc42.org/section-3/[Context and Scope] в документации arc42.
+
+****
+
+
+=== Бизнес контекст
+
+[role="arc42help"]
+****
+.Содержание
+Спецификация *всех* коммуникационных партнеров (пользователи, ИТ-системы, ...) с пояснениями входных и выходных данных или интерфейсов, специфичных для предметной области.
+При желании вы можете добавить специфичные для домена форматы или протоколы связи.
+
+.Мотивация
+Все заинтересованные стороны должны понимать, какими данными система обменивается со средой.
+
+.Форма
+Все виды диаграмм, изображающих систему в виде черного ящика и определяющих интерфейсы домена для коммуникационных партнеров.
+
+В качестве альтернативы (или дополнительно) можно использовать таблицу.
+Заголовок таблицы — это имя вашей системы, три столбца содержат имя партнера, с которым происходит коммуникация, входы и выходы.
+
+****
+
+**<Диаграмма или таблица>**
+
+**<необязательно: объяснение внешних доменных интерфейсов>**
+
+=== Технический контекст
+
+[role="arc42help"]
+****
+.Содержание
+Технические интерфейсы (каналы и среды передачи), связывающие вашу систему с окружающей средой. Кроме того, сопоставление ввода/вывода, специфичного для предметной области, с каналами, то есть объяснение, какой ввод/вывод использует какой канал.
+
+.Мотивация
+Многие заинтересованные стороны принимают архитектурные решения на основе технических интерфейсов между системой и ее контекстом. Зачастую разработчики инфраструктуры или оборудования выбирают эти технические интерфейсы.
+
+.Форма
+Например, диаграмма развертывания UML, описывающая каналы к соседним системам,
+вместе с таблицей сопоставления, показывающей взаимосвязь между каналами и вводом/выводом.
+
+****
+
+**<Диаграмма или таблица>**
+
+**<необязательно: Пояснения к техническим интерфейсам>**
+
+**<Сопоставление ввода/вывода с каналами>**
+`;
+}
+function getSolutionStrategyTemplate() {
+    return `= 4. Стратегия решения
+
+
+[role="arc42help"]
+****
+.Содержание
+
+Краткое изложение и объяснение основных решений и стратегии, формирующих архитектуру системы. Они включают
+
+* технологические решения
+* решения о декомпозиции системы на верхнем уровне, т.е. использование архитектурного шаблона или шаблона проектирования
+* решения о том, как достичь ключевых целей в области качества
+* соответствующие организационные решения, т.е. выбор процесса разработки или делегирование определенных задач третьим лицам.
+
+.Мотивация
+Эти решения ложатся в основу вашей архитектуры. На них опираются многие другие более специфические решения или правила реализации.
+
+.Форма
+Объяснения таких ключевых решений должны быть короткими.
+
+Мотивируйте решение (и почему было решено именно так)
+на основе постановки задачи, целей в области качества и ключевых ограничений.
+Подробности см. в следующих разделах.
+
+.Дальнейшая информация
+
+Смотрите https://docs.arc42.org/section-4/[Стратегия решения] в документации arc42.
+
+****
+`;
+}
+function getBuildingBlockViewTemplate() {
+    return `= 5. Представление строительных блоков
+
+[role="arc42help"]
+****
+.Содержание
+Представление строительных блоков показывает статическую декомпозицию системы на строительные блоки (модули, компоненты, подсистемы, классы, интерфейсы, пакеты, библиотеки, фреймворки, слои, партиции, уровни, функции, макросы, операции, структуры данных, ...) а также их зависимости (отношения, ассоциации, ...)
+
+Это представление является обязательным для любой архитектурной документации.
+По аналогии с домом это _план этажа_.
+
+.Мотивация
+Поддерживайте структуру исходного кода понятной с помощью абстракций.
+
+Это позволит вам общаться с заинтересованными лицами на абстрактном уровне, не раскрывая деталей реализации.
+
+.Форма
+Представление стандартных блоков представляет собой иерархическую коллекцию черных и белых ящиков.
+(см. рисунок ниже) и их описания.
+
+image::05_building_blocks-EN.png["Иерархия строительных блоков"]
+
+*Уровень 1* представляет собой описание всей системы в виде «белого ящика» вместе с описаниями всех содержащихся строительных блоков в виде «черных ящиков».
+
+*Уровень 2* раскрывает детали некоторых строительных блоков уровня 1.
+Таким образом, он содержит описание «белого ящика» выбранных строительных блоков уровня 1 вместе с описанием их внутренних строительных блоков как «черных ящиков».
+
+*Уровень 3* увеличивает масштаб выбранных строительных блоков уровня 2 и так далее.
+
+.Дальнейшая информация
+
+Смотрите https://docs.arc42.org/section-5/[Представление строительных блоков] в документации arc42.
+
+****
+
+=== Система в общем («белый ящик»)
+
+[role="arc42help"]
+****
+Здесь вы описываете декомпозицию всей системы, используя следующий шаблон белого ящика. Описание содержит
+
+* обзорную схему
+* мотивацию декомпозиции
+* описания содержащихся строительных блоков («черный ящик»). Для них мы предлагаем альтернативы:
+
+** используйте _одну_ таблицу для краткого и практичного обзора всех содержащихся строительных блоков и их интерфейсов
+** используйте список описаний составных частей «черного ящика» в соответствии с шаблоном «черного ящика» (см. ниже).
+
+В зависимости от выбранного вами инструмента этот список может состоять из подглав (в текстовых файлах), подстраниц (в Wiki) или вложенных элементов (в инструменте моделирования).
+
+
+* (необязательно:) важные интерфейсы, которые не объясняются в шаблонах «черного ящика» строительных блоков, но очень важны для понимания белого «ящика».
+Поскольку существует так много способов указать интерфейсы, почему бы не предоставить для них специальный шаблон.
+В худшем случае вам придется указать и описать синтаксис, семантику, протоколы, обработку ошибок,
+ограничения, версии, качества, необходимые совместимости и многое другое.
+В лучшем случае вам сойдут с рук примеры или простые подписи.
+
+****
+
+_**<Обзорная диаграмма>**_
+
+Мотивация::
+
+_<текстовое объяснение>_
+
+
+Содержащиеся строительные блоки::
+_<Описание строительных блоков (черные ящики)>_
+
+Важные интерфейсы::
+_<Описание важных интерфейсов>_
+
+[role="arc42help"]
+****
+
+Вставьте свои объяснения черных «ящиков» из уровня 1:
+
+Если вы используете табличную форму, вы будете описывать только свои черные ящики с именем и
+ответственности по следующей схеме:
+
+[cols="1,2" options="header"]
+|===
+| **Название** | **Ответственность**
+| _<Черный ящик 1>_ | _<Текст>_
+| _<Черный ящик 2>_ | _<Текст>_
+|===
+
+
+Если вы используете список описаний «черного ящика», то вы заполняете отдельный шаблон «черного ящика» для каждого важного стандартного блока.
+Его заголовок — название черного ящика.
+
+****
+
+
+==== <Название черного ящика 1>
+
+[role="arc42help"]
+****
+
+Здесь вы описываете <черный ящик 1>
+в соответствии со следующим шаблоном:
+
+* Цель/ответственность
+* Интерфейс(ы), если они не описаны отдельными абзацами. Эти интерфейсы могут включать качества и характеристики производительности.
+* (Необязательно) Характеристики качества/производительности «черного ящика», например, доступность, поведение во время выполнения, ....
+* (Необязательно) расположение каталога/файла
+* (Необязательно) Выполненные требования (если вам нужна прослеживаемость к требованиям).
+* (Необязательно) Открытые вопросы/проблемы/риски
+
+****
+
+_<Цель/обязанности>_
+
+_<Интерфейс(ы)>_
+
+_<(Необязательно) Характеристики качества/производительности>_
+
+_<(Необязательно) Папка/Расположение файла>_
+
+_<(Необязательно) Выполненные требования>_
+
+_<(необязательно) Открытые проблемы/проблемы/риски>_
+
+
+
+
+==== <Название черного ящика 2>
+
+_<шаблон черного ящика>_
+
+==== <Название черного ящика n>
+
+_<шаблон черного ящика>_
+
+
+==== <Название интерфейса 1>
+
+...
+
+==== <Название интерфейса m>
+
+
+
+
+=== Уровень 2
+
+[role="arc42help"]
+****
+Здесь вы можете указать внутреннюю структуру (некоторых) строительных блоков первого уровня в виде «белого ящика».
+
+Вы должны решить, какие строительные блоки вашей системы достаточно важны, чтобы оправдать такое подробное описание.
+Пожалуйста, предпочтите релевантность полноте. Укажите важные, неожиданные, рискованные, сложные или изменчивые строительные блоки.
+Исключите нормальные, простые, скучные или стандартизированные части вашей системы.
+****
+
+==== Белый ящик _<строительный блок 1>_
+
+[role="arc42help"]
+****
+...описывает внутреннюю структуру _строительного блока 1_.
+
+****
+
+_<шаблон белого ящика>_
+
+==== Белый ящик _<строительный блок 2>_
+
+
+_<шаблон белого ящика>_
+
+...
+
+==== Белый ящик _<строительный блок m>_
+
+
+_<шаблон белого ящика>_
+
+
+
+=== Уровень 3
+
+[role="arc42help"]
+****
+
+Если вам нужны более подробные уровни вашей архитектуры, скопируйте эту
+часть arc42 для дополнительных уровней.
+****
+
+
+==== Белый ящик <_строительный блок x.1_>
+
+[role="arc42help"]
+****
+Описывает внутреннюю структуру _строительного блока x.1_.
+****
+
+
+_<шаблон белого ящика>_
+
+
+==== Белый ящик <_строительный блок x.2_>
+
+_<шаблон белого ящика>_
+
+
+
+==== Белый ящик <_строительный блок y.1_>
+
+_<шаблон белого ящика>_
+`;
+}
+function getRuntimeViewTemplate() {
+    return `= 6. Представление времени выполнения
+
+[role="arc42help"]
+****
+.Содержание
+Представление времени выполнения описывает конкретное поведение и взаимодействие строительных блоков системы в виде сценариев из следующих областей:
+
+* важные варианты использования или функции: как строительные блоки их выполняют?
+* взаимодействия на критических внешних интерфейсах: как строительные блоки взаимодействуют с пользователями и соседними системами?
+* эксплуатация и администрирование: запуск, запуск, остановка
+* сценарии ошибок и исключений
+
+Примечание: Основным критерием выбора возможных сценариев (последовательностей, рабочих процессов) является их *архитектурная релевантность*.
+*Не* нужно без надобности описывать большое количество сценариев.
+Вам лучше задокументировать репрезентативный выбор.
+
+.Мотивация
+Вы должны понимать, как (экземпляры) строительных блоков вашей системы выполняют свою работу и взаимодействуют во время выполнения.
+В основном вы будете фиксировать сценарии в своей документации, чтобы сообщить о своей архитектуре заинтересованным сторонам, которые менее склонны или не способны читать и понимать статические модели (представление стандартных блоков, представление развертывания).
+
+.Форма
+Существует множество обозначений для описания сценариев, например.
+
+* пронумерованный список шагов (на естественном языке)
+* диаграммы деятельности (activity diagrams) или блок-схемы
+* диаграммы последовательности (sequence diagrams)
+* BPMN или EPC (цепочки обработки событий)
+* конечные автоматы
+* ...
+
+.Дальнейшая информация
+Смотри https://docs.arc42.org/section-6/[Представление времени выполнения] в документации arc42.
+
+****
+
+=== <Сценарий времени выполнения 1>
+
+* _<вставьте диаграмму выполнения или текстовое описание сценария>_
+* _<вставьте описание важных аспектов взаимодействия между экземплярами стандартных блоков, изображенных на этой диаграмме.>_
+
+=== <Сценарий времени выполнения 2>
+
+=== ...
+
+=== <Сценарий времени выполнения n>
+`;
+}
+function getDeploymentViewTemplate() {
+    return `= 7. Представления развертывания
+
+[role="arc42help"]
+****
+Представление развертывания описывает:
+
+1. техническую инфраструктуру, используемую для работы вашей системы, с элементами инфраструктуры, такими как географические местоположения, среды, компьютеры, процессоры, каналы и сетевые топологии, а также другие элементы инфраструктуры и
+
+2. сопоставление строительных блоков (программного обеспечения) с этими элементами инфраструктуры.
+
+Часто системы выполняются в разных средах, например. среда разработки, тестовая среда, продакшн.
+В таких случаях вы должны задокументировать все соответствующие среды.
+
+Особенно важно задокументировать представление развертывания, если ваше программное обеспечение выполняется в виде распределенной системы с более чем одним компьютером, процессором, сервером или контейнером; или когда вы проектируете и создаете свои собственные аппаратные процессоры и микросхемы.
+
+С точки зрения программного обеспечения достаточно зафиксировать только те элементы инфраструктуры, которые необходимы для демонстрации развертывания ваших строительных блоков.
+Архитекторы аппаратного обеспечения могут пойти дальше и описать инфраструктуру с любым уровнем детализации, который им необходим.
+
+.Мотивация
+Программное обеспечение не работает без аппаратного обеспечения.
+Эта базовая инфраструктура может и будет влиять на систему и/или некоторые сквозные (сквозные) концепции.
+Поэтому необходимо знать инфраструктуру.
+
+.Форма
+Возможно, схема развертывания самого высокого уровня уже содержится в разделе 3.2. в виде технического контекста с собственной инфраструктурой, описанной ОДНИМ черным ящиком.
+В этом разделе можно раскрыть этот черный ящик, используя дополнительные диаграммы развертывания:
+
+* UML предлагает диаграммы развертывания, чтобы выразить это представление.
+Используйте его, возможно, с вложенными диаграммами, в случае если ваша инфраструктура более сложна.
+* Если заинтересованные стороны (связанные с аппаратным обеспечением) предпочитают другие виды диаграмм, а не диаграмму развертывания, позвольте им использовать любой вид, способный отображать узлы и каналы инфраструктуры.
+
+.Дальнейшая информация
+Смотри https://docs.arc42.org/section-7/[Представление развертывания] в документации arc42.
+
+****
+
+=== Инфраструктурный уровень 1
+
+[role="arc42help"]
+****
+
+Опишите (обычно в комбинации диаграмм, таблиц и текста):
+
+* распределение системы по нескольким местоположениям, средам, компьютерам, процессорам и т. д., а также физическим соединениям между ними
+* важные обоснования или мотивы для этой структуры развертывания
+* характеристики качества и/или производительности этой инфраструктуры
+* сопоставление программных артефактов с элементами этой инфраструктуры
+
+Для нескольких сред или альтернативных развертываний скопируйте и адаптируйте этот раздел arc42 для всех соответствующих сред.
+****
+
+_**<Обзорная диаграмма>**_
+
+Мотивация::
+
+_<объяснение в текстовом виде>_
+
+Характеристики качества и/или производительности::
+
+_<объяснение в текстовом виде>_
+
+Сопоставление строительных блоков с инфраструктурой::
+_<описание сопоставления>_
+
+=== Инфраструктурный уровень 2
+
+[role="arc42help"]
+****
+Сюда можно включить внутреннюю структуру (некоторых) Инфраструктурных элементов уровня 1.
+
+Пожалуйста, скопируйте структуру уровня 1 для каждого выбранного элемента.
+****
+
+==== _<Инфраструктурный элемент 1>_
+
+_<диаграмма + объяснение>_
+
+==== _<Инфраструктурный элемент 2>_
+
+_<диаграмма + объяснение>_
+
+...
+
+==== _<Инфраструктурный элемент n>_
+
+_<диаграмма + объяснение>_
+`;
+}
+function getConceptsTemplate() {
+    return `= 8. Сквозные концепции
+
+
+[role="arc42help"]
+****
+.Содержание
+В этом разделе описываются главные правила и идеи решений, которые применимы к нескольким частям (= сквозные) вашей системы.
+Такие концепции часто связаны с несколькими строительными блоками.
+Они могут включать множество различных тем, таких как
+
+* модели, особенно модели предметной области
+* архитектура или шаблоны дизайна
+* правила использования конкретных технологий
+* принципиальные, часто технические решения всеобъемлющего (= сквозного) характера
+* правила реализации
+
+
+.Мотивация
+
+Концепции составляют основу _концептуальной целостности_ (непротиворечивости, однородности) архитектуры.
+Таким образом, они являются важным вкладом в достижение внутренних качеств вашей системы.
+
+Некоторые из этих концепций не могут быть отнесены к отдельным строительным блокам, например к безопасности или производительности.
+
+.Форма
+Форма может быть разнообразной:
+
+* концептуальные документы любой структуры
+* сквозные фрагменты моделей или сценарии с использованием обозначений архитектурных представлений
+* примеры реализации, особенно для технических концепций
+* ссылка на типичное использование стандартных фреймворков (например, использование Hibernate для объектно-реляционного сопоставления)
+
+.Структура
+Потенциальная (но не обязательная) структура этого раздела может быть следующей:
+
+* Концепции домена
+* Концепции взаимодействия с пользователем (UX)
+* Концепции безопасности и защиты
+* Архитектура и шаблоны проектирования
+* "Под капотом"
+* концепции развития
+* операционные концепции
+
+Примечание: может быть сложно отнести отдельные концепции к одной конкретной теме в этом списке.
+
+image::08-concepts-EN.drawio.png["Возможные темы для сквозных концепций"]
+
+
+.Дальнейшая информация
+
+Смотри https://docs.arc42.org/section-8/[Концепции] в документации arc42.
+****
+
+
+=== _<Концепция 1>_
+
+_<объяснение>_
+
+
+
+=== _<Концепция 2>_
+
+_<объяснение>_
+
+...
+
+=== _<Концепция n>_
+
+_<объяснение>_
+`;
+}
+function getArchitectureDecisionsTemplate() {
+    return `= 9. Архитектурные решения
+
+
+[role="arc42help"]
+****
+.Содержание
+Важные, дорогие, крупномасштабные или рискованные архитектурные решения, включая их обоснование.
+Под «решениями» мы подразумеваем выбор одной альтернативы на основе заданных критериев.
+
+Решите сами, следует ли документировать архитектурное решение в этом центральном разделе, или лучше документировать это локально (например, в шаблоне белого ящика одного стандартного блока).
+
+Избегайте избыточности.
+Обратитесь к разделу 4, где вы уже зафиксировали наиболее важные решения вашей архитектуры.
+
+.Мотивация
+Заинтересованные лица вашей системы должны иметь возможность понять и проследить ваши решения.
+
+.Форма
+Различные варианты:
+
+* ADR (https://cognitect.com/blog/2011/11/15/documenting-architecture-decisions[Документирование архитектурных решений]) для каждого важного решения
+* Список или таблица, упорядоченные по важности и последствиям или:
+* подробнее в виде отдельных разделов по решению
+
+.Дальнейшая информация
+
+Смотри https://docs.arc42.org/section-9/[Архитектурные решения] в документации arc42.
+Там вы найдете ссылки и примеры по ADR.
+
+****
+`;
+}
+function getQualityRequirementsTemplate() {
+    return `= 10. Требования к качеству
+
+
+[role="arc42help"]
+****
+
+.Содержание
+Этот раздел содержит все требования к качеству в виде дерева качества со сценариями. Наиболее важные из них уже были описаны в разделе 1.2. (цели качества)
+
+Здесь вы также можете зафиксировать требования к качеству с меньшим приоритетом,
+не создающие высоких рисков будучи не полностью достигнутыми.
+
+.Мотивация
+Поскольку требования к качеству будут иметь большое влияние на архитектурные
+решения, вы должны знать что действительно важно для каждой из заинтересованных сторон (конкретно и измеримо).
+
+.Дальнейшая информация
+
+Смотри https://docs.arc42.org/section-10/[Требования к качеству] в документации arc42.
+
+****
+
+=== Дерево качества
+
+[role="arc42help"]
+****
+.Содержание
+Дерево качества (как определено в ATAM — Architecture Tradeoff Analysis Method) со сценариями качества/оценки в виде листьев.
+
+.Мотивация
+Древовидная структура с приоритетами обеспечивает обзор большого количества требований к качеству.
+
+.Форма
+Дерево качества представляет собой высокоуровневый обзор целей и требований в области качества:
+
+* древовидное уточнение термина «качество». Используйте «качество» или «полезность» в качестве корня
+* майндмпеп с категориями качества в качестве основных ветвей
+
+В любом случае дерево должно включать ссылки на сценарии следующего раздела.
+
+****
+
+=== Сценарии качества
+
+[role="arc42help"]
+****
+.Содержание
+Конкретизация (иногда расплывчатых или неявных) требований к качеству с использованием сценариев (качества).
+
+Эти сценарии описывают, что должно произойти, когда в систему поступает стимул.
+
+Для архитекторов важны два вида сценариев:
+
+* Сценарии использования (также называемые сценариями приложений или сценариями вариантов использования) описывают реакцию системы во время выполнения на определенный стимул. Сюда также входят сценарии, описывающие эффективность или производительность системы. Пример: Система реагирует на запрос пользователя в течение одной секунды.
+* Сценарии изменений описывают модификацию системы или ее ближайшего окружения. Пример: Реализована дополнительная функциональность или изменены требования к атрибуту качества.
+
+.Мотивация
+Сценарии конкретизируют требования к качеству и позволяют
+легче измерить или решить, выполнены ли они.
+
+Особенно, когда вы хотите оценить свою архитектуру, используя такие методы, как
+ATAM вам необходимо описать ваши цели в области качества (из раздела 1.2)
+точнее до уровня сценариев, которые можно обсуждать и оценивать.
+
+.Форма
+Табличный или произвольный текст.
+****
+`;
+}
+function getTechnicalRisksTemplate() {
+    return `= 11. Риски и технический долг
+
+
+[role="arc42help"]
+****
+.Содержание
+Список выявленных технических рисков или технических долгов, упорядоченный по приоритету
+
+.Мотивация
+«Управление рисками — это управление проектами для взрослых» (Тим Листер, Atlantic Systems Guild).
+
+Это должно быть вашим девизом для систематического обнаружения и оценки рисков и технических задолженностей в архитектуре, которые потребуются управляющим заинтересованным сторонам (например, руководителям проектов, владельцам продуктов) в рамках общего анализа рисков и планирования измерений.
+
+.Форма
+Список рисков и/или технических долгов, возможно, включая предлагаемые меры по минимизации, смягчению или предотвращению рисков или сокращению технических долгов.
+
+
+.Дальнейшая информация
+
+Смотри https://docs.arc42.org/section-11/[Риски и технический долг] в документации arc42.
+
+****
+`;
+}
+function getGlossaryTemplate() {
+    return `= 12. Глоссарий
+
+[role="arc42help"]
+****
+.Содержание
+Наиболее важные доменные и технические термины, которые ваши заинтересованные стороны используют при обсуждении системы.
+
+Вы также можете использовать глоссарий в качестве источника переводов, если вы работаете в многоязычной команде.
+
+.Мотивация
+Вы должны четко определить свои условия, чтобы все заинтересованные стороны
+
+* имели одинаковое понимание этих терминов
+* не использовали синонимы и омонимы
+
+.Форма
+
+Таблица со столбцами <Термин> и <Определение>.
+
+Потенциально больше столбцов на случай, если вам понадобятся переводы.
+
+
+.Дальнейшая информация
+
+Смотри https://docs.arc42.org/section-12/[Глоссарий] в документации arc42.
+
+****
+
+[cols="e,2e" options="header"]
+|===
+|Термин |Определение
+
+|<Термин-1>
+|<определение-1>
+
+|<Термин-2>
+|<определение-2>
+|===
+`;
+}
+/**
+ * Get the Russian workflow guide in AsciiDoc format
+ */
+export function getWorkflowGuide() {
+    return `= Руководство по документированию архитектуры arc42
+
+== Обзор
+
+Это руководство поможет вам документировать архитектуру программного обеспечения с использованием шаблона arc42. Шаблон arc42 — это практичный, проверенный шаблон для документирования архитектуры программного обеспечения и систем.
+
+== Доступные языки
+
+Этот arc42 MCP Server поддерживает несколько языков для документации:
+
+[options="header",cols="1,2,2"]
+|===
+|Код |Язык |Название на родном языке
+|EN |Английский |English
+|DE |Немецкий |Deutsch
+|CZ |Чешский |Čeština
+|ES |Испанский |Español
+|FR |Французский |Français
+|IT |Итальянский |Italiano
+|NL |Нидерландский |Nederlands
+|PT |Португальский |Português
+|RU |Русский |Русский
+|UKR |Украинский |Українська
+|ZH |Китайский |中文
+|===
+
+== Начало работы
+
+=== Шаг 1: Инициализация рабочего пространства
+
+Используйте инструмент \`arc42-init\` для создания рабочего пространства документации:
+
+[source]
+----
+arc42-init(projectName: "Мой проект", language: "RU")
+----
+
+Вы можете указать другой язык, используя код ISO языка.
+
+=== Шаг 2: Проверка статуса
+
+Используйте \`arc42-status\` для просмотра текущего состояния документации:
+
+[source]
+----
+arc42-status()
+----
+
+=== Шаг 3: Генерация шаблонов разделов
+
+Используйте \`generate-template\` для получения подробных шаблонов для каждого раздела:
+
+[source]
+----
+generate-template(section: "01_introduction_and_goals", language: "RU")
+----
+
+== 12 разделов arc42
+
+. *Введение и цели* — Начните здесь! Определите, что вы создаете и зачем.
+. *Архитектурные ограничения* — Что вам НЕ разрешено делать?
+. *Контекст и рамки* — Что входит, а что нет?
+. *Стратегия решения* — Высокоуровневый подход к решению задачи.
+. *Представление строительных блоков* — Статическая структура системы.
+. *Представление времени выполнения* — Динамическое поведение и сценарии.
+. *Представление развертывания* — Как система развертывается и эксплуатируется?
+. *Сквозные концепции* — Шаблоны, используемые во всей системе.
+. *Архитектурные решения* — Важные решения и их обоснование.
+. *Требования к качеству* — Конкретные сценарии качества.
+. *Риски и технический долг* — Что может пойти не так?
+. *Глоссарий* — Определите ваши термины.
+
+== Лучшие практики
+
+. *Начните с раздела 1* — Понимание целей является основополагающим
+. *Будьте краткими* — arc42 прагматичен, а не бюрократичен
+. *Используйте диаграммы* — Одна картинка стоит тысячи слов
+. *Документируйте решения* — Будущий вы поблагодарит настоящего вас
+. *Итерируйте* — Документация архитектуры никогда не бывает «завершенной»
+
+== Доступные инструменты
+
+* \`arc42-init\` — Инициализация рабочего пространства документации
+* \`arc42-status\` — Проверка статуса документации
+* \`generate-template\` — Генерация шаблонов разделов
+* \`update-section\` — Обновление содержимого раздела
+* \`get-section\` — Чтение содержимого раздела
+* \`arc42-workflow-guide\` — Показать это руководство
+
+== Ресурсы
+
+* link:https://arc42.org/[Веб-сайт arc42]
+* link:https://docs.arc42.org/[Документация arc42]
+* link:https://arc42.org/examples[Примеры arc42]
+`;
+}
+/**
+ * Get the Russian README content in AsciiDoc format
+ */
+export function getReadmeContent(projectName) {
+    const name = projectName || 'Проект';
+    return `= ${name} — Документация архитектуры
+
+Этот каталог содержит документацию архитектуры для ${name}, следующую шаблону arc42.
+
+== Структура
+
+* \`sections/\` — Отдельные файлы разделов AsciiDoc (12 разделов)
+* \`images/\` — Диаграммы и изображения
+* \`arc42-documentation.adoc\` — Основной объединенный документ
+* \`config.yaml\` — Конфигурация
+
+== 12 разделов arc42
+
+. *Введение и цели* — Требования, цели качества, заинтересованные стороны
+. *Архитектурные ограничения* — Технические и организационные ограничения
+. *Контекст и рамки* — Бизнес и технический контекст
+. *Стратегия решения* — Фундаментальные решения и стратегии
+. *Представление строительных блоков* — Статическая декомпозиция
+. *Представление времени выполнения* — Динамическое поведение
+. *Представление развертывания* — Инфраструктура и развертывание
+. *Сквозные концепции* — Общие правила и подходы
+. *Архитектурные решения* — Важные решения (ADR)
+. *Требования к качеству* — Дерево качества и сценарии
+. *Риски и технический долг* — Известные проблемы и риски
+. *Глоссарий* — Важные термины
+
+== Начало работы
+
+. Начните с раздела 1: Введение и цели
+. Работайте над разделами итеративно
+. Используйте диаграммы для иллюстрации концепций
+. Сосредоточьтесь на решениях, а не на деталях реализации
+
+== Генерация документации
+
+Используйте инструменты MCP для:
+
+* Проверки статуса: \`arc42-status\`
+* Генерации шаблонов: \`generate-template\`
+* Обновления разделов: \`update-section\`
+
+== Ресурсы
+
+* link:https://arc42.org/[Веб-сайт arc42]
+* link:https://docs.arc42.org/[Документация arc42]
+* link:https://arc42.org/examples[Примеры arc42]
+`;
+}
+//# sourceMappingURL=templates-asciidoc.js.map