'; }
+
+function sourceList() {
+ const sources = [
+ {
+ title: 'OpenTelemetry Trace API',
+ version: 'v1.31.0, immutable commit 3985e212f0ef5439daf9b10f0ee490e349c69368, 13 March 2024',
+ href: 'https://raw.githubusercontent.com/open-telemetry/opentelemetry-specification/3985e212f0ef5439daf9b10f0ee490e349c69368/specification/trace/api.md',
+ fact: 'Версия v1.31.0 описывает span как операцию со start/end timestamps, attributes и timestamped events; event содержит name, timestamp и optional attributes.',
+ boundary: 'Это контракт observability API. Он не определяет UX, не назначает owner и не доказывает, что конкретная команда правильно измеряет путь.',
+ },
+ {
+ title: 'W3C Performance Timeline',
+ version: 'Candidate Recommendation Draft, 21 May 2025',
+ href: 'https://www.w3.org/TR/2025/CRD-performance-timeline-20250521/',
+ fact: 'Рекомендация определяет PerformanceEntry и поля name, entryType, startTime и duration для наблюдения временных записей.',
+ boundary: 'Стандарт относится к web performance API; здесь он служит только примером явного имени, типа и времени записи, не рецептом измерения внутреннего сервиса.',
+ },
+ {
+ title: 'GOV.UK Service Manual: Measuring the success of your service',
+ version: 'immutable Internet Archive capture 2024-07-05T18:32:52Z of official GOV.UK guidance; public update 6 August 2018',
+ href: 'https://web.archive.org/web/20240705183252id_/https://www.gov.uk/service-manual/measuring-success/measuring-the-success-of-your-service',
+ fact: 'Закреплённый снимок предлагает сочетать performance metrics с user research, не полагаться только на digital analytics и для пути смотреть completion/time периодически.',
+ boundary: 'Это публичная методическая рекомендация, а не универсальный KPI, договор об измерениях или доказательство эффекта этой учебной модели.',
+ },
+ {
+ title: 'GOV.UK Service Manual: Set up and manage user support',
+ version: 'immutable Internet Archive capture 2023-05-12T13:53:36Z of official GOV.UK guidance; public update 24 November 2016',
+ href: 'https://web.archive.org/web/20230512135336id_/https://www.gov.uk/service-manual/helping-people-to-use-your-service/set-up-and-manage-user-support',
+ fact: 'Закреплённый снимок предлагает использовать feedback user support для улучшения, группировать запросы и связывать их с внутренней командой, способной действовать.',
+ boundary: 'Support signal указывает направление проверки; он не заменяет исследование, не показывает причинность и не является готовым решением.',
+ },
+ ];
+ return '
|$)/, ''));
+}
+function revision(meta, parts) {
+ const contentHtml = parts.join('\n') + '\n' + h2('Проверяемые источники') + '\n' + sourceList();
+ const proseLength = bodyText(contentHtml).length;
+ if (proseLength < 5000 || proseLength > 15000) throw new Error(meta.slug + ': основной текст вне диапазона 5 000–15 000 знаков: ' + proseLength);
+ return Object.freeze({ ...meta, contentHtml });
+}
+
+export const revisions = Object.freeze([
+ revision({
+ slug: 'editorial-2025-06-practice-developer-experience',
+ title: 'Удобство внутреннего инструмента: наблюдать путь одной задачи',
+ excerpt: 'Вместо единого DX-score — путь задачи, явные ожидания, отдельные типы свидетельств, owner и проверяемая стоп-ветка.',
+ readingMinutes: 12,
+ }, [
+ p('Проблема. Внутренний инструмент может формально выдавать результат и всё же создавать очередь ожидания: человек отправляет запрос, не видит владельца, спрашивает в соседнем канале и ждёт ручного обхода. Цена ошибки — не только лишние минуты. Команда теряет время на повторные объяснения, а руководитель получает красивый средний показатель без места, где задача застряла.'),
+ p('Поэтому «удобно» здесь не оценка и не один DX-score. Это наблюдаемая гипотеза о конкретном пути: какая роль вошла в задачу, какое событие зафиксировало переход, где возникло ожидание, какой сигнал пришёл от поддержки, кто может изменить путь и что будет считаться доказательством эффекта. Если хотя бы один слой неизвестен, правильный результат — не смелый вывод, а остановка утверждения.'),
+ h2('Начать с одной задачи, а не с общей метрики'),
+ p('Берём одну повторяемую задачу с ясным результатом. В учебной модели это запрос synthetic sandbox access: роль открыла задачу, отправила заявку, вошла в approval wait, получила подтверждение и увидела synthetic result. Такой маршрут мал, но в нём уже видны разные вопросы. Событие отвечает на вопрос «что и когда произошло». Наблюдение UX отвечает на вопрос «что человек не понял». Support signal показывает формулировку обращения. Решение владельца связывает сигнал с изменением. Доказательство эффекта появляется только после сопоставимой повторной проверки.'),
+ p('Это не попытка свести работу людей к секундомеру. Даже точное время ожидания не говорит, почему оно появилось: причиной может быть очередь, недостающая подсказка, право, внешний процесс или неверно выбранная задача. Временная запись нужна как адрес для исследования. Она не заменяет разговор с ролью и не делает support card статистикой.'),
+ figure('/assets/editorial/2025/developer-experience-2025-task-journey.svg', 'Вертикальная схема учебной задачи: вход, наблюдаемое ожидание, support signal, решение владельца, повторная проверка и safe stop без доказательства эффекта.', 'Рисунок 1. Путь одной fixed synthetic задачи. Каждый блок несёт разный вид свидетельства; красная ветка запрещает заявлять эффект без сопоставимой проверки.'),
+ h2('Пять видов свидетельств не стоит склеивать'),
+ p('Смешение слоёв начинается безобидно: карточка поддержки становится «проблемой всех», одна отметка в журнале — «доказательством боли», а решение владельца — «улучшением». В результате команда спорит о вкусе, потому что вопрос, источник и сила вывода потерялись. Короткая таблица возвращает границу каждому объекту.'),
+ table(
+ ['Слой', 'Что он фиксирует', 'Чего он не доказывает', 'Следующее действие'],
+ [
+ ['UX-observation', 'Роль не понимает, кому принадлежит следующий шаг.', 'Частоту, причину задержки и эффект будущего изменения.', 'Проверить формулировку задачи и задать вопрос роли.'],
+ ['Instrumented event', 'Имя этапа, порядок и fixed wait bucket.', 'Удовлетворённость, мотивацию, реальную нагрузку или причинность.', 'Проверить контракт события и место ожидания.'],
+ ['Support signal', 'Повторяемую категорию вопроса и команду, способную действовать.', 'Масштаб затронутых людей и корректность решения.', 'Собрать hypothesis для owner.'],
+ ['Decision', 'Owner, target stage, границу изменения и stop rule.', 'Фактический эффект от решения.', 'Запустить ограниченную повторную проверку.'],
+ ['Effect evidence', 'Сопоставление после изменения при той же границе.', 'Причинность вне этой границы и перенос на другие роли.', 'Обновить решение либо сохранить unresolved claim.'],
+ ],
+ ),
+ p('Термин instrumented event здесь узкий: запись с именем этапа, временем, источником и контрактом полей. OpenTelemetry описывает event как имя, timestamp и optional attributes, а span — как операцию со временем начала и конца. Это помогает не оставлять в логе безымянное «что-то произошло», но не навязывает модель удобства. Аналогично, W3C Performance Timeline показывает ценность явных name, type, startTime и duration для временной записи; применимость стандарта заканчивается на форме записи.'),
+ h2('Контракт задачи: короткий, но fail-closed'),
+ p('Вместо свободного объекта фиксируем exact keys. У задачи есть declared role, цель и expected result; у каждого stage event — stage, occurredAt, observedAt, waitBucket, evidence kind и source. Unknowns не прячутся в заметке: они обязательное поле. Candidate change привязан к owner, одному этапу, bounded window и стоп-условию. Если поле пропало, роль подменена или кто-то объявил effect established, evaluator возвращает safe stop.'),
+ pre("import { createFixedJourneyInput, evaluateJourney, verifyFixture } from './upgrade-2025-06.mjs';\n\nconst result = evaluateJourney(createFixedJourneyInput());\n\nconsole.log({\n accepted: result.accepted,\n effectClaim: result.effectClaim,\n productionEffect: result.productionEffect,\n});\nconsole.log(verifyFixture());\n// true, 'not-established', false\n// PASS fixture: 33/33 assertions"),
+ p('Положительный результат не означает, что инструмент удобен. Он означает лишь, что учебный объект не потерял границы: событие принадлежит нужной задаче, порядок этапов не сломан, источник соответствует виду свидетельства, unknowns перечислены, а claim не превышает доказательство. Это полезнее ложной уверенности: ошибочный объект не попадает в отчёт и не превращается в бэклог «исправить UX вообще».'),
+ h2('Как увидеть ожидание без игры в среднее'),
+ p('Для маршрута полезны buckets, а не единственная средняя длительность. В model approval wait лежит в корзине 30m–1h. Она отмечает, где путь замедлился, но не говорит, что все остальные ожидания одинаковы. Рядом нужны роль, этап, причина, неизвестное и owner. Иначе короткие задачи могут скрыть один критичный стоп, а длинная задача — искусственно ухудшить агрегат.'),
+ p('Корзина должна быть заранее объявлена как часть контракта, а не подобрана после просмотра результата. В этом примере диапазон 30m–1h не несёт точности до секунды и не претендует на норму. Он всего лишь связывает два approval events и делает очередь вопросом для owner. Если команда изменит границы bucket, она должна сохранить версию схемы и не сравнивать новые значения со старыми так, будто смысл поля остался прежним.'),
+ p('Полезный контрпример: два одинаковых wait buckets могут означать разные действия. В одном случае роль не знает, что заявка уже в очереди; тогда проверяется ясность статуса. В другом owner виден, статус понятен, но этап зависит от заранее известного внешнего окна; тогда интерфейс не обязан обещать мгновенный результат. Событие в обоих случаях похоже, но UX question, решение и допустимый effect claim различаются.'),
+ figure('/assets/editorial/2025/developer-experience-2025-wait-time-histogram.svg', 'Учебная гистограмма с корзинами 0–5 минут, 30 минут–1 час и более часа, снабжённая предупреждением: корзина ожидания не измеряет удобство и не объясняет причину.', 'Рисунок 2. Корзина времени — адрес проверки, а не итоговая оценка удобства. Числа в рисунке synthetic и не описывают реальный инструмент.'),
+ p('Официальное руководство GOV.UK предлагает для транзакций соединять performance metrics с user research и не полагаться только на digital analytics. Для end-to-end пути оно отдельно называет completion и время выполнения задачи, повторяемые во времени. Это не предписание сделать один KPI: наоборот, источник даёт основание держать разные данные рядом и не выдавать один канал за картину целиком.'),
+ h2('Минимальный цикл работы владельца'),
+ p('Практика становится инженерной, когда у неё есть короткий порядок и право остановиться. Ниже нет запуска реального исследования или telemetry: это порядок вопросов, который затем можно применить в своей среде с отдельными правами и данными.'),
+ '
Назвать одну задачу и её видимый результат; не включать весь onboarding в один маршрут.
Зафиксировать declared role, этапы и события с ограниченными полями; отдельно записать source каждого факта.
Положить wait bucket рядом с этапом, а не выдавать его за причину.
Привязать UX-observation и support signal к вопросу, не к готовому решению.
Назвать owner, candidate change, comparison boundary и bounded follow-up.
Если сопоставимого evidence нет, оставить effect claim в состоянии not-established и остановиться.
',
+ h2('Где модель намеренно останавливается'),
+ p('Граница практики. Эта статья описывает порядок постановки вопроса, а не способ незаметно собрать данные. Synthetic task, timestamps и buckets — опоры для разговора о пути; они не представляют журнал внутреннего инструмента. Код выполняет только проверку литералов в памяти: у него нет client, очереди, файлового ввода или отправки события.'),
+ p('Модель не знает, сколько людей сталкивается с задачей, не измеряет cognitive cost, не хранит обращение и не различает реальный канал поддержки. Она также не может доказать, что показ owner до submit уменьшит ожидание: это может снять вопрос маршрутизации и не изменить approval queue. Такая граница — не недостаток текста, а защита от неверного решения.'),
+ p('Следующий проверяемый шаг. В своём инструменте выберите одну роль и один path, согласуйте owner и минимальный event contract, затем заранее запишите условие, при котором вы откажетесь от вывода. Только после этого собирайте разрешённые данные и сопоставляйте тот же маршрут до и после изменения.'),
+ ]),
+ revision({
+ slug: 'editorial-2025-06-mechanism-developer-experience',
+ title: 'Удобство внутреннего инструмента: контракт наблюдаемой задачи',
+ excerpt: 'Как построить технический контракт для пути задачи: событие, ожидание, UX-observation, support signal, решение владельца и безопасная остановка claim.',
+ readingMinutes: 13,
+ }, [
+ p('Проблема. Инструмент может успешно завершать запрос, но инженер всё равно ждёт неизвестного владельца, повторяет данные вручную и открывает обходной путь. Цена ошибки — очередь из невидимых переключений контекста: владелец видит только успешные ответы, а команда платит за уточнения, повторные заявки и решения, которые нельзя проверить.'),
+ p('Техническая реакция часто слишком узка: добавить один таймер, построить среднее и назвать его DX. Это стирает разницу между событием, наблюдением, сигналом поддержки, решением и доказательством эффекта. Нужен не широкий dashboard, а строгий контракт одной задачи. Он делает неизвестное видимым, не позволяет подменить role или результат и заставляет остановить claim, когда сопоставимых данных нет.'),
+ h2('Единица наблюдения — задача с границей'),
+ p('Задача — не экран и не сервис целиком. Это переход от ясного входа к проверяемому результату для одной declared role. В fixed model входом служит открытие synthetic access request, результатом — synthetic confirmation. Между ними есть пять stage events. Каждый event содержит два времени: occurredAt — когда факт задан в модели, и observedAt — когда он зафиксирован. Их равенство в fixture не обещает, что так будет в настоящем инструменте; это просто делает допущение явным.'),
+ p('OpenTelemetry Trace API полезен здесь только как пример дисциплины данных: span имеет start/end timestamps и набор timestamped events, а event имеет name, timestamp и optional attributes. В model мы не строим trace и не отправляем telemetry. Мы заимствуем ровно одно свойство: без имени события, времени и источника невозможно проверить, что сравнивают. W3C Performance Timeline таким же образом показывает, почему у записи должны быть name, type, startTime и duration, но не подсказывает, какую бизнес-метрику считать.'),
+ h2('Поля контракта и их неочевидные границы'),
+ table(
+ ['Поле', 'Зачем нужно', 'Проверка', 'Запрещённый вывод'],
+ [
+ ['declaredRole', 'Отделяет путь одной роли от общего «пользователя».', 'Exact match с fixed role record.', 'Роль не равна реальной учётной записи или праву.'],
+ ['stage + order', 'Делает видимым переход и место задержки.', 'Пять допустимых стадий в строгом порядке.', 'Порядок не объясняет причину ожидания.'],
+ ['occurredAt / observedAt', 'Разделяет время факта и время его фиксации.', 'ISO-формат, occurredAt ≤ observedAt, хронология.', 'Время не измеряет cognitive cost.'],
+ ['waitBucket', 'Помечает диапазон ожидания, не создавая ложную точность.', 'Для approval stages только 30m–1h.', 'Корзина не является общим DX-score.'],
+ ['evidenceKind / source', 'Не даёт observation выдать за event или signal за доказательство.', 'Фиксированная пара kind → source.', 'Источник не делает утверждение причинным.'],
+ ['knownUnknowns', 'Сохраняет пробелы модели рядом с решением.', 'Непустой dense array обязательных строк.', 'Unknown нельзя заменить удобным предположением.'],
+ ],
+ ),
+ p('Exact contract — это не бюрократия ради JSON. Он задаёт точку, в которой evaluator обязан отказать. Лишнее поле unboundedScore отвергается так же, как недостающее knownUnknowns. Удалённый элемент array становится sparse и тоже отвергается. Циклический объект нельзя канонизировать — значит его нельзя использовать как незаметный носитель контекста. Эти проверки защищают не от злого пользователя, а от тихого расползания смыслов между заметкой, таблицей и решением.'),
+ h2('Пять слов «свидетельства» означают пять разных операций'),
+ p('UX-observation — наблюдение о том, как declared role понимает шаг; в примере это неясный owner после submit. Instrumented event — контрактный факт о переходе. Support signal — группировка формулировки вопроса, которой может воспользоваться команда. Decision — выбор owner: показать owner до submit и проверить именно этот этап. Effect evidence — сопоставимый результат после изменения. Нельзя переставить их местами: support signal не устанавливает эффект, а event не заменяет разговор о смысле задачи.'),
+ figure('/assets/editorial/2025/developer-experience-2025-feedback-loop.svg', 'Вертикальная петля Observe, Decide, Change, Recheck и Effect evidence, в которой UX-observation, event и support signal разделены, а без сопоставимого evidence выбран safe stop.', 'Рисунок 3. Решение появляется после наблюдений, а доказательство эффекта — только после повторной проверки по той же границе.'),
+ p('Руководство GOV.UK советует не опираться только на digital analytics, а сочетать метрики с user research. Для support оно отдельно предлагает использовать feedback в улучшении и связывать сигналы с внутренней группой, которая способна действовать. В этой статье из этого следует узкий инженерный вывод: signal должен иметь owner и следующий вопрос, но не получает статус универсальной метрики или готового backlog item.'),
+ h2('Fail-closed evaluator: отказ лучше выдуманного эффекта'),
+ p('Evaluator сначала проверяет, что весь input — canonical JSON из plain records и dense arrays. Затем он сверяет exact keys, model version, declared role, event source, порядок и wait bucket. После этого он проверяет change, bounded follow-up и effect claim. В нормальном case decision разрешает только candidate change hypothesis; поле effectClaim остаётся not-established, а productionEffect — false.'),
+ pre("import { createFixedJourneyInput, evaluateJourney } from './upgrade-2025-06.mjs';\n\nconst forged = createFixedJourneyInput();\nforged.claimedEffect.status = 'established';\nforged.claimedEffect.evidenceRefs = ['one-record-is-not-a-comparison'];\n\nconst result = evaluateJourney(forged);\nconsole.log(result.reason);\n// effect-claim-not-evidenced\nconsole.log(result.nextAction);\n// Safe stop: preserve the rejected claim ..."),
+ p('Этот отрицательный путь важнее happy path. Если одна fixed record уже названа эффектом, следующая команда почти неизбежно перенесёт вывод на другие роли и задачи. Без comparison boundary она не заметит, что изменились инструкция, входная роль, порядок этапов или канал обращения. Поэтому claim сначала должен быть слабым и точно сформулированным: «effect not established».'),
+ h2('Почему wait bucket не равен когнитивной стоимости'),
+ p('Cognitive cost проявляется не только во времени. Человек может ждать недолго и всё же переключаться между системами, искать ответ, сомневаться в результате или выполнять ручный обход. И наоборот, долгий этап может быть ожидаемым внешним ограничением. В model wait bucket помечает approval wait, а UX-observation фиксирует непонятного owner. Эти объекты лежат рядом, но evaluator не умножает их и не строит synthetic score.'),
+ p('Разделение occurredAt и observedAt защищает ещё от одной подмены. Если источник заметил событие позже самого перехода, это может быть свойством доставки записи, а не свойством задачи. Fixture задаёт одинаковые значения, чтобы не моделировать транспорт, но evaluator всё равно требует явный порядок. В production-подобной системе надо отдельно решить, какой timestamp отвечает на вопрос о пути, а какой — на вопрос о наблюдателе; текст не переносит это решение автоматически.'),
+ p('Не следует также превращать отсутствие сигнала в доказательство удобства. У роли может не быть доступного канала, у support может быть другая классификация, а событие может не покрывать ручной шаг. Поэтому отрицательный результат выглядит скромно: «в этой границе доказательства нет». Для техлида это полезный ответ — он сохраняет место для следующего измерения и не тратит квартал на спор о метрике, которой никто не может объяснить.'),
+ figure('/assets/editorial/2025/developer-experience-2025-wait-time-histogram.svg', 'Учебная гистограмма ожидания с тремя временными корзинами и подписью, что корзина показывает место исследования, но не объясняет причину или удобство.', 'Рисунок 4. Время помогает выбрать участок пути для проверки. Оно не заменяет evidence о понимании, поддержке или эффекте.'),
+ h2('Как применить контракт без ложной универсальности'),
+ p('Переносить следует не значения из fixture, а порядок работы. Реальная команда отдельно определяет права на сбор данных, защиту идентификаторов, допустимые sources, retention и owner. Сначала ей нужен task boundary, потом event naming, затем разрешённый user research и support categorisation. После изменения она повторяет ту же задачу для сопоставимой роли и заранее знает, что сделает, если evidence недостаточно.'),
+ '
Сформулируйте цель одной задачи и ожидаемый результат в наблюдаемой форме.
Назовите role, stages, event source и wait bucket; уберите поля, которые никто не сможет интерпретировать.
Отдельно запишите UX question, support category и known unknowns.
Назначьте owner candidate change и запретите эффект claim до bounded follow-up.
Повторите сравнение на той же границе или верните решение в safe stop.
',
+ h2('Ограничения и следующий тест'),
+ p('Граница механизма. Evaluator проверяет структуру и семантические пары fixed records, а не правдивость внешнего мира. Он намеренно не содержит payload, user identifier, transport, часы или integration point. Даже accepted decision не запускает change: он только разрешает сохранить hypothesis для ограниченной следующей проверки.'),
+ p('Даже строгая fixture не моделирует реальную задержку, человека, поддерживающую команду или качество интерфейса. Она не знает безопасность telemetry, не проверяет доступы и не подменяет user research. Её результат — только доказательство того, что неверный contract не станет положительным решением.'),
+ p('Следующий проверяемый шаг. Возьмите один реальный, но разрешённый для исследования путь и составьте сначала пустой contract: какие fields вы обязуетесь собрать, какие unknowns ожидаете и какой result заставит остановить claim. Проверьте этот contract с owner до изменения интерфейса.'),
+ ]),
+ revision({
+ slug: 'editorial-2025-06-field-developer-experience',
+ title: 'Удобство внутреннего инструмента: учебный кейс без ложного эффекта',
+ excerpt: 'Разбор одной fixed synthetic задачи: где появляется ожидание, как отделить сигнал от решения и почему честный safe stop лучше выдуманного улучшения.',
+ readingMinutes: 13,
+ }, [
+ p('Проблема. Новая возможность внутреннего инструмента может «работать»: заявка подтверждается, итог появляется, ошибки нет. Но путь оставляет человека в очереди между submit и approval, вынуждает искать владельца и создавать ручный обход. Цена ошибки — скрытая: потерянный контекст, повторная работа support и решение о redesign на основании одного яркого сообщения.'),
+ p('Разберём такой случай без притворства, что у нас есть production telemetry или реальные пользователи. Учебный кейс использует только fixed in-memory literals. Его цель — показать форму доказательства: как разделить observation, event, support signal, decision и effect evidence; как записать unknown; и как остановить утверждение, если одно synthetic прохождение не даёт основания говорить «стало удобнее».'),
+ h2('Случай: запрос sandbox access'),
+ p('Declared role synthetic-platform-engineer открывает одну fixed задачу. В 09:03 она отправляет request, в 09:04 путь входит в approval wait, в 09:41 получает confirmation и в 09:45 фиксирует synthetic result. Между submit и received задан bucket 30m–1h. Рядом есть UX-observation: роль не понимает, кто отвечает за следующий шаг. Отдельно лежит support signal с категорией routing-unclear.'),
+ p('Важно, что четыре объекта не дублируют друг друга. Event не говорит, что ожидание плохо. Observation не сообщает, что так происходит у всех. Support signal не измеряет число обращений. Candidate change не доказывает эффект. Это намеренное ограничение: одна задача может обнаружить дырку в вопросе, но не может без повторной проверки объявить исправление успешным.'),
+ figure('/assets/editorial/2025/developer-experience-2025-task-journey.svg', 'Схема одной учебной задачи от входа к результату: approval wait, неясный owner, support signal, candidate change и безопасная остановка эффекта без сопоставимого evidence.', 'Рисунок 5. В кейсе время ожидания и неопределённость owner встречаются на одном пути, но остаются разными видами данных.'),
+ h2('Карта случая: факт, гипотеза и неизвестное'),
+ table(
+ ['Артефакт fixed model', 'Что можно сказать', 'Чего нельзя сказать', 'Кто продолжает'],
+ [
+ ['stage event approval.wait.started → received', 'В учебной записи есть этап с bucket 30m–1h.', 'Почему ждём, насколько это часто и насколько это дорого.', 'Journey owner проверяет путь.'],
+ ['UX-observation owner-unclear', 'Declared role не видит ответственного после submit.', 'Что label гарантированно снизит время или frustration.', 'Research owner уточняет вопрос.'],
+ ['support signal routing-unclear', 'Есть фиксированная формулировка категории обращения.', 'Что это самый частый запрос или причина задержки.', 'Support + journey owner выбирают проверку.'],
+ ['candidate change owner-before-submit', 'Есть гипотеза о маршрутизации и один target stage.', 'Что изменение уже улучшило инструмент.', 'Journey owner запускает bounded follow-up.'],
+ ['claimed effect not-established', 'Модель честно оставляет вывод открытым.', 'Что эффект отсутствует в действительности.', 'Owner сохраняет stop path до нового evidence.'],
+ ],
+ ),
+ p('GOV.UK Service Manual предлагает смотреть на end-to-end journey через задачи, completion и время, периодически сравнивая результаты, а не объявлять качество по одному цифровому сигналу. Для support руководство предлагает использовать feedback в улучшении и различать команды, которые могут действовать. В кейсе эти факты не становятся готовой методикой: они объясняют, почему route, signal и owner должны быть видны отдельно.'),
+ h2('Что именно проверяет fixture'),
+ p('Fixture не «прогоняет инструмент». Она делает обратное: атакует учебный договор. Baseline принимается, потому что в нём exact keys, fixed version, declared role, пять ordered events, source для каждого вида evidence, непустые unknowns, owner, bounded follow-up и unresolved claim. Затем fixture подделывает event source, role и result; удаляет fields; создаёт sparse array и cyclic value; нарушает временной порядок. Каждый такой input должен завершиться closed decision.'),
+ pre("import { createFixedJourneyInput, evaluateJourney, verifyFixture } from './upgrade-2025-06.mjs';\n\nconsole.log(verifyFixture());\n// PASS fixture: 33/33 assertions\n\nconst input = createFixedJourneyInput();\ndelete input.knownUnknowns;\nconsole.log(evaluateJourney(input).reason);\n// invalid-task-contract"),
+ p('Отдельный test на forged result особенно важен. Он меняет claimedEffect.status на established и добавляет одну ссылку на несопоставимую запись. Evaluator отвечает effect-claim-not-evidenced. Он не пытается «оценить, похоже ли на правду»: единственный допустимый путь — safe stop, пока не появятся одинаковые task boundary, role, stage order, evidence labels и bounded window.'),
+ h2('Почему manual workaround — сигнал, а не готовая причина'),
+ p('В реальном расследовании ручной обход часто выглядит как очевидное доказательство плохого UX. Но он может быть следствием срочности, местной привычки, старой инструкции или ограничения процесса, которого интерфейс честно не может снять. Поэтому в model обход не записан как причинный факт. Вместо этого support signal указывает на routing question, UX-observation формулирует непонимание owner, а candidate change ограничен тем, что может проверить: показать ответственного до submit.'),
+ p('Такая формулировка экономит время. Она не просит сначала переписать весь flow. Она требует выяснить, существует ли сравнимое свидетельство: тот же role проходит тот же task после небольшой change и фиксирует тот же набор полей. Если нет — решение не объявляют неудачным и не объявляют удачным. Его статус остаётся hypothesis-only.'),
+ p('Сравнимость — не декоративное слово. Если после изменения мы поменяли роль, результат задачи, источник события или правило bucket, разница может появиться в данных без изменения самого пути. Поэтому comparisonBoundary перечисляет role, objective, order и evidence labels. Он не делает эксперимент причинным, но не позволяет незаметно сравнить разные процессы. Бounded window тоже не обещает статистический срок: он ограничивает, когда owner обязан вернуться к вопросу или признать evidence недостаточным.'),
+ p('В кейсе safe stop не означает «ничего не делать». Он означает конкретное действие без эффекта claim: исправить broken contract, уточнить source, провести разрешённую проверку или закрыть hypothesis. Такая дисциплина особенно полезна для внутренних инструментов, где один очень громкий отзыв легко перетягивает приоритет, а тихая, но массовая задержка остаётся между системами. Сначала появляется проверяемый путь, потом — обоснование инвестиции.'),
+ h2('Петля: от сигнала к повторной проверке'),
+ figure('/assets/editorial/2025/developer-experience-2025-feedback-loop.svg', 'Вертикальная петля с наблюдением, решением владельца, ограниченным изменением, повторной проверкой и safe stop при отсутствии сопоставимых доказательств.', 'Рисунок 6. Цикл запрещает перескочить от support signal к заявлению об эффекте.'),
+ p('Владелец в кейсе — synthetic-journey-owner. Это не право на production change, а явный адрес ответственности внутри модели. Его decision описывает hypothesis, target stage, expected evidence, bounded window и stop condition. Research owner, support owner и technical owner в реальном мире могут быть разными людьми; модель не заставляет слить их в одну роль. Она только не позволяет оставить вопрос «кто продолжает» без ответа.'),
+ '
Сохранить исходную формулировку задачи, role и expected result.
Отметить stages и wait bucket без вывода о причине.
Приложить UX-observation и support signal как разные источники.
Назначить owner, одну candidate change и bounded comparison boundary.
После повторной проверки принять только comparable evidence; иначе оставить claim not-established.
',
+ h2('Откуда берётся скрытая cognitive cost'),
+ p('Cognitive cost часто появляется между видимыми событиями: роль вспоминает, куда писать, сравнивает похожие страницы, ждёт ответа в другом канале или боится повторно отправить запрос. Ни event, ни support category сами по себе не измеряют это состояние. Поэтому полезно записать knownUnknowns заранее: нет population denominator, нет объяснения wait bucket, нет post-change comparison, нет реального support volume. Это превращает «кажется, неудобно» в план исследования, а не в необратимый вывод.'),
+ figure('/assets/editorial/2025/developer-experience-2025-wait-time-histogram.svg', 'Учебная гистограмма трёх корзин ожидания с предупреждением, что временная корзина указывает место для проверки, а не объясняет удобство или его причину.', 'Рисунок 7. Wait bucket видит задержку в пути, но не захватывает весь cognitive cost.'),
+ h2('Граница кейса и следующий проверяемый шаг'),
+ p('Граница кейса. Время 09:03–09:45, synthetic role и формулировка support card — декорации одного учебного прохода, а не вырезка из реального workflow. Кейс не образует cohort, не содержит ticket, file или telemetry record и не даёт основания утверждать, что такая же история есть у другой роли. Его единственная проверяемая ценность — показать, где decision обязан остановить неподтверждённый result.'),
+ p('Кейс не содержит реального workflow, документации, заявок, пользователей, telemetry, support tickets или network. Он не устанавливает цену ожидания и не даёт разрешение собирать такие данные. Его положительный decision — лишь согласованность JavaScript literals, а не одобрение изменения в интерфейсе.'),
+ p('Следующий проверяемый шаг. Перед любой реальной работой сформируйте с owner один research question: «видит ли эта role ответственного до submit и остаётся ли вопрос маршрутизации после этого?» Затем согласуйте допустимый источник evidence и условие safe stop. Если источник или comparison boundary не определены, не начинайте с метрики — оставьте claim открытым.'),
+ ]),
+]);
+
+if (process.argv.includes('--verify-fixture')) {
+ process.stdout.write(verifyFixture() + '\n');
+} else if (process.argv.includes('--print-revisions')) {
+ process.stdout.write(JSON.stringify(revisions));
+}