# P82 — декабрь 2024: maintenance retro

## Scope и граница выпуска

Пакет заменяет только три декабрьские overlay-ревизии:

- editorial-2024-12-practice-maintenance-retro
- editorial-2024-12-mechanism-maintenance-retro
- editorial-2024-12-field-maintenance-retro

Все owners, evidence, cases, scores, costs, timelines и outcomes в материале
являются versioned fixed synthetic in-memory literals из
synthetic-maintenance-retro/2024-12-v1. Скрипт не читает filesystem, Git, CI,
network, telemetry, incident archive, clock, team history или production state.
Он не выполняет deployment, deletion, rollback или любой внешний change.

## Досье источников

Все URL ниже проверены обычным HTTPS GET 2026-07-31: HTTP 200, без
аутентификации и TLS bypass. Это источники, существовавшие до декабря 2024.

| Источник, дата или версия | Точная поддерживаемая мысль | Ограничение источника |
| --- | --- | --- |
| [Google SRE Book, Chapter 15: Postmortem Culture: Learning from Failure](https://sre.google/sre-book/postmortem-culture/), первое издание 2016 | Postmortem фиксирует воздействие, причины, response и follow-up; триггеры и owner action item должны быть определены, а обучение не равно поиску виноватого. | Не задаёт maintenance backlog score, не подтверждает историю читателя и не санкционирует change. |
| [Google SRE Book, Chapter 5: Eliminating Toil](https://sre.google/sre-book/eliminating-toil/), первое издание 2016 | Повторяемую ручную операционную работу полезно отличать от устойчивой инженерной ценности; источник toil стоит устранять осознанно. | Не говорит, что любая ручная проверка является долгом, и не даёт универсальную оценку времени или денег. |
| [NIST SP 800-30 Rev. 1: Guide for Conducting Risk Assessments](https://csrc.nist.gov/pubs/sp/800/30/r1/final), final September 2012 | Risk assessment служит информацией для выбора курса действий; контекст и uncertainty нельзя подменять одним числом. | Не утверждает, что формула из этой статьи — вероятность, стандартная шкала или финансовый прогноз. |
| [NIST SP 800-40 Rev. 4: Guide to Enterprise Patch Management Planning](https://csrc.nist.gov/pubs/sp/800/40/r4/final), final April 2022 | Preventive maintenance различает identification, prioritization, implementation и verification. | Не заменяет локальные ownership rules, approval, tests, change window или проверку конкретной системы. |

Покрытие на статью:

- Practice использует минимум Google postmortem и Google toil; NIST SP 800-30
  и SP 800-40 уточняют границу оценки и preventive maintenance.
- Mechanism использует минимум NIST SP 800-30 и SP 800-40; Google toil
  объясняет, почему повторяемость не равна любой ручной работе.
- Field использует минимум Google postmortem и NIST SP 800-40; Google toil и
  NIST SP 800-30 ограничивают выводы из повторяемости и score.

## Проход 1 — факты и техника

Проверено вручную:

- Во всех трёх текстах первые два абзаца называют ситуацию и цену ошибки.
  Нет утверждения о реальном incident, team history, customer, metric, saving
  или production outcome.
- Practice отделяет symptom, risk, cost class, owner role, evidence boundary и
  one next experiment. Ценой названы только учебные классы: interrupt, delay
  review и recheck, а не деньги.
- Mechanism прямо называет formula
  impact * repeatability + uncertainty * 2 - evidenceStrength учебной.
  Heatmap задаёт только review order; score не назван вероятностью, бюджетом,
  прогнозом или разрешением на change.
- Field имеет три fixed synthetic case, T0–T3 timeline, recheck loop,
  stop rule, restore question и next-quarter plan. Stop path отбрасывает
  draft; это не production rollback.
- Контракт модели требует exact keys и canonical fixed report/draft. Fixture
  покрывает unknown keys, missing fields, forged score, dense arrays, sparse
  nested array, cyclic report, cyclic draft, mutated actions и safe stop path.
- Техническая проверка не нашла imports, fetch, filesystem, child process или
  HTTP client в overlay script. Внешние URL находятся только в опубликованном
  source list и не являются I/O модели.

После этого прохода уточнена формулировка «явная граница доказательств» и
убраны неясные смешанные фразы, чтобы reader не принимал synthetic artefact за
наблюдение реальной системы.

## Проход 2 — редактура и голос

Прочитаны полные тела статей до списка источников:

| Статья | Объём основного текста | Редакторский вывод |
| --- | ---: | --- |
| Practice | 10 020 знаков | Уплотнена вокруг review-card: symptom → причина → проверка → один experiment. Есть таблицы, code example, figure, ограничения и следующий шаг. |
| Mechanism | 10 259 знаков | Score сначала ограничен evidence types и priority boundary. Из текста убраны обещания точной стоимости и «математического» решения. |
| Field | 11 665 знаков | Три case не превращены в выдуманное ретро. Timeline отделяет draft, recheck и отдельный human-approved change. |

Голос соответствует декабрю 2024: системный практик показывает наблюдаемый
артефакт, цену решения, ownership и путь проверки, но не пишет от лица
универсальной платформенной стратегии 2027 года. Термины раскрываются рядом с
сценарием, а абзацы следуют цепочке symptom → причина → проверка → действие.

## Проход 3 — визуал и выпуск

Проверено вручную:

- SVG открыты и просмотрены после Sharp-render на ширине 375 px:
  heatmap — 375×271, change timeline — 375×240, review loop — 375×260.
  Основные заголовки, карточки, направления и boundary остаются читаемыми;
  HTML-подписи дополняют схему без скрытого смысла.
- У каждой статьи есть meaningful alt, figcaption, минимум одна HTML table,
  compact reproducible code example, numbered action sequence, source section,
  limitations и concrete next step.
- XML проходит xmllint. Safety scan не нашёл script, foreignObject,
  javascript URI, data:image или event handler.
- node --check проходит.
- node scripts/upgrade-2024-12.mjs --verify-fixture проходит:
  PASS fixture: 31/31 assertions.
- npm run audit:draft -- scripts/upgrade-2024-12.mjs проходит для всех трёх
  slug.

До интеграции registry, README, очередь, articles.json, staging, commit и push
намеренно не выполнялись: они были вне разрешённого scope P82.

## Вердикт

P82 готов как самостоятельный draft-пакет. Он может быть интегрирован отдельным
выпускным шагом после review общего registry; текущий пакет сам ничего не
публикует и не изменяет внешний state.

## Выпуск после независимой приёмки

Основной редактор провёл отдельные три прохода уже после интеграции:

1. **Факты и техника.** Официальная глава Google о postmortem подтверждает
   запись воздействия, причин, действий и follow-up, а также необходимость
   заранее определить triggers. Глава о toil отделяет повторяемую ручную работу
   от работы с устойчивой ценностью. Официальные страницы NIST подтверждают
   final-статус SP 800-30 Rev. 1 (сентябрь 2012) и SP 800-40 Rev. 4 (апрель
   2022); вторая явно различает identifying, prioritizing, installing и
   verifying. Эти источники не расширены до утверждений о реальной системе.
   `node --check` и fixture повторно прошли: **31/31**.
2. **Редактура и голос.** Полные тексты перечитаны после интеграции. В ранних
   абзацах раскрыты рабочие англоязычные термины: `review`, `card`,
   `evidence boundary`, `score`, `timeline`, `recheck` и `stop`. Это оставляет
   язык коротким для инженера 2024 года, но не заставляет читателя угадывать
   смысл терминов. `audit:draft` и целевой `audit:articles` подтвердили объём,
   по рисунку, коду и минимум две таблицы в каждой статье.
3. **Визуал и выпуск.** Все три SVG снова отрисованы Sharp на 375 px и
   просмотрены: heatmap — 375×271, timeline — 375×240, loop — 375×260;
   подписи, карточки и стрелки остаются читаемыми. XML и safety scan чисты.
   Реестр содержит **241 уникальную** ревизию. `git diff --check` чист, а
   `npm run build` успешно собрал **374** статические страницы.

Вердикт: три декабрьские статьи готовы к отдельному публикационному коммиту.