edit full article archive to publication standard

editorial/QUALITY_STANDARD.md

@@ -37,6 +37,27 @@
 - В серии из трёх статей нельзя растягивать один общий вводный блок на practice, mechanism и field. Краткое определение можно повторить для самостоятельного чтения, но у каждой статьи должны быть свой главный вопрос, пример, таблица или схема, ограничение и следующий шаг.
 - Заголовок обещает ровно тот вопрос, на который отвечает текст. Результат не объявляется «универсальным», если он зависит от версии, нагрузки, прав или архитектуры проекта.
 
+## Редактура по принципам «Пиши, сокращай»
+
+Название раздела отсылает к книге Максима Ильяхова и Людмилы Сарычевой, но не заменяет её чтение и не требует копировать авторские формулировки. Для этого корпуса применяем практический набор правил: читателю проще удерживать короткие смысловые блоки, видеть конкретного действующего участника и находить главное в начале текста.
+
+- Начинаем с действия читателя: какой симптом он увидит, что проверит и какое решение сможет принять. Историю автора, план публикации и отчёт о проделанной редактуре в статью не переносим.
+- Пишем о системе через действующие лица и операции: «клиент отправляет запрос», «валидатор отклоняет поле», «сборщик публикует артефакт». Отглагольные существительные и безличные конструкции заменяем глаголом, если при этом не теряется технический смысл.
+- В каждом абзаце одна функция: факт, механизм, пример, ограничение или действие. Главное утверждение ставим в начало абзаца и таблицы; пояснение и исключение идут следом.
+- Убираем слова, которые не меняют решение: вводные оценки, канцелярские связки, тавтологию, усилители и обещания без доказательства. «Осуществить проверку» становится «проверить», «позволяет выявить» — «показывает», если это действительно тот смысл.
+- Делим перегруженные предложения. Ориентир — не более 35 слов в обычном предложении; более длинное оставляем только для точного определения, формулы или условия, которое иначе станет двусмысленным. Команды, идентификаторы, JSON и код не переписываем ради длины.
+- Каждое обобщение подкрепляем наблюдаемым примером, числом, таблицей, кодом или источником. Если данных нет, называем границу знания прямо и формулируем следующий способ проверки, без фиктивного результата.
+- Технический термин сохраняем, когда он точнее бытового слова. При первом появлении даём короткую расшифровку; одинаковый термин не заменяем декоративными синонимами.
+- Сокращение не должно убрать механизм, контрпример, ограничение или проверку. Цель редактора — высокая плотность смысла, а не минимальное число знаков.
+
+### Три прохода по длинному тексту
+
+1. **Смысл.** Вынести проблему и цену ошибки в начало, проверить один главный вопрос, убрать рассуждения о личности автора, планах, корреляциях и ходе написания.
+2. **Слова и предложения.** Заменить абстрактные связки конкретными действиями, сократить повторения и канцелярит, разделить перегруженные предложения, проверить согласование терминов и субъектов.
+3. **Доказательства.** Вернуть только те примеры, таблицы, схемы, числа и ссылки, которые помогают проверить вывод. Сверить код с описанием и убедиться, что после сокращения не исчезли версия, условие применимости и ограничение.
+
+Автоматический аудит подсвечивает мета-лексику, шаблонные обороты и слишком длинные предложения. Финальное решение принимает редактор: техническая формула, API-идентификатор и фрагмент кода могут быть длинными по необходимости, а обычная фраза — только по причине, которую можно объяснить.
+
 ## Голос автора
 
 - Для 2017–2018 годов — практичная, тёплая заметка инженера: «давайте разберём», осторожные выводы, внимание к реальной ошибке и следующему шагу.