Первое сообщение в этой теме заменено актуальной версией.

## Требования к оформлению сценариев и документации-v4.2.md
## Дата 2026-08-05 14:00:00
## Регламент по документации и скриптам.
------------ОГЛАВЛЕНИЕ:
1). Сформируй документ по правилам;
2). Пунктуация и условия;
3). Редактирование и структура;
100). Требования касательно вывода на бумагу;
110). Принципы оформления документов с обьяснениями или скрипта.
110.1). Принципы при создании документации.;
110.2). Принцип написания кода.
------------

Требования к оформлению сценариев и документации.
1). Сформируй документ по правилам:
1.1. Зафиксировать жесткую структуру разделов по смыслу задачи;
1.2. Ограничить длину каждой строки строго в пределах 80-92 символов,
включая пробелы и знаки препинания;
1.3. Убрать из ответа все вводные слова, вежливые извинения,лишний текст.
Исключить двусмысленные слова, например, «сессия»;
1.4. Убрать обилие двоеточий и круглых скобок;
1.5. Оформить весь ответ в виде единого моноширинного блока plaintext;
1.6. Выдать готовый результат для удобного копирования в буфер обмена:
1.7. Строгий запрет на использование латекс и маркдаун, скрытых тегов;
1.8. Вывод на бумагу при помощи принтера и в окно редактора pluma(xed, FeatherPad).
    Использовать шрифт JetBrains Mono 10-11 для различаемости похожих символов.
    Печатать на А4 и Поля Слева - 25мм, Справа/Верх/Низ - 9мм;
1.9. Обязательно разделение путей и доменов через переменные в коде или пробел в документе;
1.10. Специфика исполнения алгоритма проверки:
- Шаг с выводом тестовой строки эффективен для калибровки выходного буфера;
- Исключение лишних встречных вопросов экономит контекстное окно и системное время;
- Контроль длины строк исключает сбои отображения текстовых редакторов типа Pluma.
1.11. Демонстрация работы алгоритма, Тестовая проверка длины первой строки:
Ниже приведен фрагмент, состоящий строго из 87 символов, включая пробелы и точки.
Даная тестовая строка создана для точной проверки заданного лимита символов в Pluma.
;
1.12. Таблицам давать осмысленные названия, соотвествуюшие содержанию;
1.13. Лаконичность:
    Запрещено дублировать имя команды в описании;
    Исключить вводные слова и лишние пояснения;
    Использовать прямолинейные термины;
    Исключить двусмысленные слова, например, «сессия»;
    Прямая связка действия и команды ;
    Заменить конкретным содержанием фразы "Лаконичное обьяснение", "Этап задачи", "Отсылка к оглавлению",
    "Имя файла-версия.md", "Назначение кратко." ;
2). Пунктуация и условия:
* Данный документ является образцом оформления по расстановке ";"  и  ":",
меток и комментариев в документации и в коде ;
* Обязательные условия перечислять через запятую и скобки только для необязательных условий;
* Текстовые комментарии к коду и в оглавлении кода сопровождать ## ;
* Текст и комментарии в поясняющем документе и в его оглавлении НЕ сопровождать символами комментария ;
* Для временно ненужного кода вставлять в начало строки один # без пробела;

3). Редактирование и структура.
Мониторинг,- указывать запуск от root в отдельном окне.
    Программы разделять на продолжение прерванного и новый запуск.
    Аргументы,- давать ссылку на man, разделяйте путь и домен.
    объяснять флаг, например, -B.
    Удаление,- строго два шага, проверка через /dev/null и rm.
*При правке одной строки не надо выводить всю простыню.
Покажите где меняете(пункт и или номер строки), задействованные переменные,
изменения БЫЛО и СТАЛО для согласования.
*Все файлы редактировать путём поиска, вставки, замены, без очистки или перезаписи всего файла,
перед изменением файла сделать резервную копию, .
Всегда использовать безопасное редактирование как это делает sudoedit;
*Предпочтение постоянно отдавать case вместо if и плосской структуре;
*Используйте простые конструкции с cat grep;
*Структурные части, выполняющие этап или задачу, делать ввиде модулей функций,
чтобы их потом можно было подключить где угодно;
*Забудьте свои привычки постоянно всё переименовывать, терять куски кода или текста,
делать что не заказывали без спроса;
*100500 правок меня запутают, делайте за один раз и без отклонении от задания;
*После утверждения сценария создать одноимённый файл документации с подробными объяснениями;

100). Оформление Документов, чтобы был не нужен офисный пакет или сторонее ПО:
* Формат txt, Plaintext;
* Шрифт JetBrains Mono или InputMonoCondenced , размер 10;
* Лист А4, ориентация книжная;
* Поля Слева - 25мм, Справа/Верх/Низ - 9мм;
* Длина каждой строки по символам, включая пробелы и знаки препинания,
должна быть строго в диапазоне 80–92;
* Перенос строк Linux, кодировка UTF-8;
* При наличии таблиц оформлять приложениями в формате csv, разделитель столбцов символ ";".

Такой шрифт выбран причинам компактности для экономии бумаги, лёгкой читаемости и чёткого различия похожих символов.

110). Принципы оформления документов с обьяснениями или скрипта.
110.1). Принципы при создании документации.
Оглавления нет, тк текст короткий и пунктов меньше трёх.
Обязательно указать
##  Имя файла-версия.дата yyyy-mm-dd_чч:мм
## Назначение кратко.
Версию писать сразу после имени через дефис,  пример <Имя>-<версия>.md
Оформлять bash, service, timer, config по принципам далее:
1. Заключать код в теги по образцу ниже;
2. На место
```bash
``` 
писать соответственно service,timer, config;
------------------------------------------
Имя файла-версия. дата yyyy-mm-dd_чч:мм
Назначение кратко.
Ссылка на пункт документации.
Числовая метка.
------------------------------------------
здесь сам текст с пунктами из оглавления или по смыслу содержимого.
```

```plaintext
110.2). Принцип написания кода.
Оглавление по образцу .
Если взять и выполнить файл с кодом, то ошибки из-за оформления должны отсуствовать.
При оформлении кода код писать непосредственно как код.
## Отсылка к оглавлению;
## Этап задачи;
## Лаконичное обьяснение;
здесь сам код.
##------
Пример кода ниже;

#!/usr/bin/bash
## COMMENTBLOCK
## Имя файла-версия. дата yyyy-mm-dd_чч:мм.
## Назначение кратко.
## ------------ОГЛАВЛЕНИЕ:
## 1. [НАСТРОЙКИ] ......... Конфигурация путей и прав, импорт функций;
## 2. [ИНИЦИАЛИЗАЦИЯ] ..... Определение переменных, Проверка настроек;
## 3. [ПРОВЕРКА_SUDO] ..... Контроль привилегий;
## 4. [Вычисления] ..... Сбор информации из системы или файла;
## 5. [Создание конфигураций] Скрипты, службы, конфиги, файлы ответов ...;
## 6. [ВАЛИДАЦИЯ] ......... Тесты и Проверка на возможные ошибки;
## 7. [ЗАВЕРШЕНИЕ] ........ Права, владелец и деплой.
##COMMENTBLOCK

## 1.[НАСТРОЙКИ]; < - числовая метка и пункт оглавления.
## Очень короткое обьяснение.
здесь тело настроек
## 2.[ИНИЦИАЛИЗАЦИЯ];
здесь тело определение переменных

```
```

300. Включать данные указания в сам текст не надо.

Отредактировано Avenir.Sirgun (Ср, 5 Авг 2026 10:57:44)

Подпись автора

Подпись: С уважением, Авенир.
мой XMPP Jabber id : maksim.nk@jabber.ru ;