progcode/editorial/reviews/2027-12-draft.md

Редакторское ревью: декабрь 2027

Пакет переписан как три самостоятельных технических материала о web security, web performance и эксплуатационной документации. Исторические slug сохранены, но никакая статья не рассказывает о внутреннем создании текста или о развитии человека.

Три содержательных прохода

editorial-2027-12-practice-author-manifesto

1. Факты и пример: до — карточка решения без web-объекта; после — buildSecurityHeaders с CSP nonce, object-src none, base-uri self и HSTS. Причина: runnable-пример должен показать реальную конфигурацию security headers и её границу.
2. Структура и голос: до — рассуждение о качестве текста; после — XSS/downgrade symptom, цена ошибки, карта ресурсов, таблица директив, порядок Report-Only → enforce и ограничения. Причина: reader должен понять, что именно защищает заголовок.
3. Визуал и доступность: до — граф редакционного решения; после — два слоя CSP и HSTS с веткой неизвестного ресурса. Причина: рисунок разделяет защиту ресурсов и схему соединения.

editorial-2027-12-mechanism-author-manifesto

1. Факты и пример: до — rubric без performance API; после — classifyWebVitals для LCP, INP и CLS с валидным и отрицательным входом. Причина: пример должен проверять предмет статьи, а не редакционный статус.
2. Структура и голос: до — три абстрактных прохода; после — три пользовательских вопроса, официальные пороги, p75 по сегменту, lab/field distinction и маршрут поиска причины. Причина: порог не должен подменять причинность.
3. Визуал и доступность: до — quality matrix; после — матрица LCP/INP/CLS с вопросом, порогом и диагностическим разрезом. Причина: мобильный читатель видит различия без длинного абзаца.

editorial-2027-12-field-author-manifesto

1. Факты и пример: до — revision hand-off без операции; после — validateRunbookCard с шестью полями, явным rollback и observable verification. Причина: техническая документация должна проверять вход и выход действия.
2. Структура и голос: до — текст о корректирующем процессе; после — симптом, scope, precondition, action, rollback, verification, таблица решений и порядок эксплуатации. Причина: статья стала инструкцией для reader-facing работы.
3. Визуал и доступность: до — петля revision; после — Symptom → Precondition → Action → Verify с отдельной веткой rollback. Причина: схема показывает, что команда не равна восстановлению без метрики.

Источники и границы применения

• W3C Content Security Policy Level 3, Working Draft: директивы CSP, nonce и режимы отчёта; статус draft требует проверки совместимости.
• RFC 6797, ноябрь 2012 года: HSTS; не защищает первый HTTP-переход.
• W3C Largest Contentful Paint, Working Draft, страница проверена 31 июля 2026 года: объект измерения LCP; не описывает весь UX.
• W3C Performance Timeline, Candidate Recommendation Draft, 21 мая 2025 года: PerformanceObserver и entries.
• Web Vitals, опубликовано 4 мая 2020 года, обновлено 31 октября 2024 года: пороги LCP/INP/CLS и p75 по сегментам.
• NIST SP 800-61r2, revision 2, май 2012 года: общая структура incident handling; не задаёт локальные команды.
• RFC 2119, март 1997 года: уровни обязательности в техническом языке; не даёт разрешение выполнять операцию.

Проверки

• node --check scripts/upgrade-2027-12.mjs — PASS.
• node scripts/upgrade-2027-12.mjs --verify-fixture — PASS, 9/9.
• npm run audit:draft -- scripts/upgrade-2027-12.mjs — PASS, 5710 / 5476 / 5686 body chars.
• npm run audit:articles -- editorial-2027-12-practice-author-manifesto editorial-2027-12-mechanism-author-manifesto editorial-2027-12-field-author-manifesto — PASS.
• xmllint --noout и SVG safety scan — PASS для трёх существующих assets.
• Ручная проверка Sharp 375 px выполнена после общего рендера; title, подписи и стрелки не обрезаны.