raise editorial quality gate and revise 2018 spring

editorial/QUALITY_STANDARD.md

@@ -18,17 +18,36 @@
 - Добавить минимум один рисунок или диаграмму, один пример и один проверяемый источник.
 - Закончить конкретным порядком действий, ограничениями и тем, что именно следует проверить в своём проекте.
 
+## Объём и плотность
+
+- Основной текст статьи, без HTML-разметки, заголовка, метаданных и списка источников, занимает от **5 000 до 15 000 знаков**.
+- Нижняя граница — не повод искусственно растягивать выводы. Если тема проста, глубину создают контекст, контрпример, проверка и решение, а не повтор одной мысли.
+- Верхняя граница — повод разбить слишком широкую тему на серию. Одна статья отвечает на один главный вопрос.
+- Каждый абзац либо добавляет факт, решение, ограничение или следующий шаг. Вступления «вообще о важности темы» и эмоциональные связки без технического смысла вырезаются.
+
+## Техническая речь
+
+- Пишем коротко и предметно: **симптом → причина → проверка → действие**. Предпочитаем глаголы и наблюдаемые факты: «запрос вернул 403», «фильтр исключает запись», «метрика выросла на 18%».
+- Один абзац — одна мысль; одно предложение не пытается одновременно описать проблему, историю команды и решение.
+- Термин используется только там, где он точнее обычного слова. После первого появления даём расшифровку или пример.
+- Не используем общие оценки: «в современном мире», «очень важно», «магическая сила», «просто нужно учитывать». Вместо них называем условие, риск или ограничение.
+- Заголовок обещает ровно тот вопрос, на который отвечает текст. Результат не объявляется «универсальным», если он зависит от версии, нагрузки, прав или архитектуры проекта.
+
 ## Голос автора
 
 - Для 2017–2018 годов — практичная, тёплая заметка инженера: «давайте разберём», осторожные выводы, внимание к реальной ошибке и следующему шагу.
+- Для 2019–2021 годов — инженер развивает T-shape: от PHP и Bitrix к фронтенду, инфраструктуре и данным. Текст всё ещё говорит от первого лица, но уже связывает решение с границами системы.
+- Для 2022–2024 годов — системный практик: появляются измерения, надёжность, безопасность, доставка и взаимодействие ролей. Утверждения становятся проверяемее, а выводы — спокойнее.
+- Для 2025–2027 годов — наставник и техлид: автор сравнивает варианты, называет стоимость решения, объясняет компромиссы и оставляет команде воспроизводимый способ работы.
 - Не подменять опыт общими фразами вроде «важно учитывать» или «магическая сила». Каждое обобщение должно опираться на случай, код, таблицу или источник.
 - Не делать вид, что исторический автор уже знает инструменты и практики 2027 года. Поздние материалы могут становиться системнее, но развитие должно быть постепенным.
 - Термины и сокращения раскрываются при первом появлении, если они не очевидны из контекста кода.
+- Полная временная карта, словарь, переходы навыков и анти-анахронизмы находятся в `editorial/voice/author-trajectory-2017-2027.md`; она обязательна для редакторского прохода.
 
 ## Тройное ревью перед публикацией
 
 1. **Факты и техника.** Сверить утверждения с источниками, проверить пример, версионные оговорки, ссылки и отсутствие ложных обещаний.
-2. **Редактура и голос.** Проверить постановку проблемы, полноту раскрытия, естественность тона соответствующего года, повторы и ясность переходов.
+2. **Редактура и голос.** Проверить постановку проблемы, объём 5–15 тыс. знаков, плотность, прагматичность речи, естественность тона соответствующего года, повторы и ясность переходов.
 3. **Визуал и выпуск.** Открыть изображения и диаграммы, проверить таблицы на узком экране, доступность `alt`/подписей, JSON, автоматический аудит и production-сборку.
 
 Результат каждой ручной проверки фиксируется рядом с партией в `editorial/reviews/`.