Проблема проявляется на hand-off: автор оставляет список ссылок и фразу «исследование подтверждает», а следующий инженер не понимает, что проверено и на какую дату. Цена — повторный поиск, решения на основе чужого пересказа и риск, что при обновлении документа команда исправит уже не ту причину. Это не лечится длинной библиографией, если в ней нет статуса конкретного claim.
Полевой метод начинается с вопроса решения, а не с обзора рынка. Сначала формулируем, что требуется выбрать или запретить; затем создаём claim card, ищем первоисточник, фиксируем version и locator, записываем наблюдение и передаём только ограниченный вывод. Проверка hand-off: получатель должен суметь назвать следующий допустимый шаг без догадки о намерении автора. Действие — делать журнал частью черновика, а не посмертным приложением.
Один вопрос, одна очередь неизвестных
Представим учебный запрос: «можно ли перенести synthetic compatibility statement в документацию?» Ответа «да» или «нет» здесь ещё нет. Сначала журнал хранит вопрос, а не вывод. Затем появляются два возможных record: pinned representation с названной версией и versionless note без неё. Они не равны только потому, что оба содержат слово support. У первого можно повторить чтение, у второго пока не ясно, какую публикацию вообще следует открыть.
Такое поле не требует собирать реальные обращения, интервью, файлы или production telemetry. Весь пример ниже состоит из fixed objects в памяти. Он не пытается исследовать живую систему и не создаёт задачу во внешнем трекере. Его функция — показать порядок журналирования: неизвестное остаётся visible until repaired. Это особенно полезно в редактуре, где соблазн написать гладкий вывод сильнее, чем признать отсутствие version pin.
| Шаг | Артефакт | Разрешённый результат | Что останавливаем |
|---|---|---|---|
| вопрос | decision question | список неизвестных | готовую рекомендацию |
| источник | version + locator | повторное открытие representation | current URL без pin |
| наблюдение | короткий artifact | узкий claim | пересказ всего документа |
| статус | next action | hand-off или repair | молчаливое допущение |
| обновление | новая card | видимая смена основания | перезапись старого evidence |
Как проходит один inspection
Inspection — это не «прочитать всё». Это конечная activity с входом и выходом. Вход: claim card с вопросом и границей времени. Действие: открыть закреплённый первичный материал и найти один locator. Выход: observed artifact и status. PROV-DM даёт здесь полезную рамку: document и extracted note — entities, а inspection связывает их без притворства, будто note сам появился вместе с фактом. Если источник не отвечает на нужную фразу, результат inspection — не плохая ссылка, а статус hold.
Ниже фиксированный example показывает счастливую, но ограниченную ветку. Карточка хранит только одно наблюдение о validator field у synthetic representation. У неё нет метрики влияния, совместимости настоящего SDK или прогноза поведения сервиса. Поэтому hand-off из функции заканчивается словами with-scope. В поле это означает: следующий участник может использовать запись как адресуемое основание для узкого вопроса, но обязан отдельно подтвердить любой более широкий вывод.
Исполняемый hand-off без внешнего следа
import { createFixedResearchLogById } from './upgrade-2025-11.mjs';
const handoff = createFixedResearchLogById('pinned-representation-v1');
console.log({ claim: handoff.claimId, status: handoff.status, next: handoff.nextAction });
// { claim: 'pinned-representation-v1', status: 'evidence-ready-for-synthetic-hand-off', next: 'hand-off-with-scope' }Все строки результата выводятся из literals, определённых в том же module. Это важно для воспроизводимости: другой запуск не зависит от текущего времени, прав на сервис, содержимого диска или изменения чужой страницы. В то же время именно поэтому результат нельзя выдать за исследование реального продукта. Fixture проверяет правила журнала: source pin заполнен, artifact конкретен, scope не пуст и нет правила, разрешающего promise как evidence.
Как вернуть недостающий факт, а не переписать вывод
Versionless card часто вызывает неверную реакцию: автор начинает дополнять текст догадками о том, какая версия имелась в виду. В журнале repair выглядит скучнее и полезнее. Статус repair-source-pin говорит: оставь claim в очереди, найди immutable primary publication, зафиксируй version, затем прочитай locator заново. Нельзя лечить пустой pin добавлением цитат вокруг current page. Новые цитаты увеличат видимость работы, но не сделают прошлое чтение воспроизводимым.
Marketing promise требует другого ремонта. У него может быть аккуратная дата и даже подписанный файл, однако в нём отсутствует измеряемый предмет. Следующий ход — либо переписать строку как наблюдение текста, либо собрать первичный метод: population, conditions, observed outcome и ограничения. Если этих данных нет, journal оставляет promise в hold. Автор не обязан спорить с обещанием; ему достаточно не использовать его как опору для технического решения.
Короткая процедура редактора
- Найти decision sentence. Подчеркнуть фразу, которая меняет рекомендацию, а не весь обзор.
- Создать claim card. Отдельно записать statement, scope и дату, к которой материал должен существовать.
- Выбрать первоисточник. Предпочесть release, commit, published PDF или dated archive capture изменяемой странице.
- Выписать один artifact. Сохранить locator и точное наблюдение, достаточное для данной фразы.
- Поставить маршрут. Hand-off допустим только с known pin; иначе repair или hold.
- Не прятать возврат. При новом evidence создать новую строку и показать, что прежний вывод был ограничен другим representation.
Проверка всей пачки, а не одной красивой ссылки
Полезное ревью проходит по обратному маршруту: от самой сильной рекомендации к карточке, затем к artifact и закреплённой публикации. Если по дороге исчезает scope, значит claim вырос в процессе письма. Если есть source pin, но нет locator, reader вынужден заново интерпретировать документ. Если есть locator, но observation заменён фразой «всё поддерживается», непонятно, какие условия скрыты. Каждая такая дыра превращается в конкретный repair, а не в эмоциональную оценку качества исследования.
Для нескольких claims не нужен общий балл достоверности. Он часто скрывает, что один важный вывод не имеет первоисточника. Лучше построить очередь по стоимости ошибки: сначала statements, которые меняют API contract, безопасность или необратимую миграцию; затем поясняющие детали. У каждой строки свой status. Так редактор может передать опубликованную часть с границами и не блокировать её из-за второстепенного вопроса, который ещё в repair.
| Состояние карточки | Что получает следующий человек | Что он не должен делать | Безопасный ход |
|---|---|---|---|
| есть version, locator, artifact и scope | ограниченный claim | распространять на чужой context | проверить условие применения |
| нет version pin | вопрос на поиск источника | цитировать current page как историю | найти dated primary publication |
| есть marketing phrase | наблюдение текста | объявлять outcome доказанным | запросить метод или сузить текст |
| появился новый source | новую card рядом со старой | переписать прошлое чтение | сравнить scope и decision |
Обновление журнала без потери времени
Когда появляется новая версия документа, не надо немедленно менять старую карточку. Сначала это отдельная observation activity: новая publication date, другой representation, новый locator и новый artifact. После сравнения можно написать, что decision не изменился, что scope сузился или что старый claim больше не годится. Такой журнал полезен в incident review и в подготовке статьи одинаково: он отвечает на вопрос, откуда взялся вывод на конкретную дату, не требуя помнить весь путь в голове.
Внутри этого draft-пакета fixture проверяет именно такие стопы. Он отклоняет произвольный input, останавливает versionless record, не разрешает marketing promise и не считает valid synthetic signature доказательством truth. Проверка не выходит за память процесса. Если после неё нужно реальное действие, это уже новый work item с собственным источником данных, правами и review. Граница не ослабляет текст: она делает следующий ответственный шаг видимым.
Граница поля и первый шаг завтра
Полевой журнал не заменяет доверенную архивную систему, редакционный процесс или оценку рисков. Он не даёт автоматического критерия, сколько первоисточников достаточно, и не позволяет решить, что один официальный PDF применим к любой архитектуре. Его нельзя использовать как способ собирать данные о людях или скрытно оценивать работу команды. В примере нет таких данных и нет side effects; это сознательное ограничение учебного механизма.
Завтра выберите одну рекомендацию, от которой зависит реальное изменение, и проведите её по петле без спешки. Получится либо короткий hand-off с pin, locator и scope, либо честная очередь repair. Оба результата лучше списка ссылок: первый можно повторить, второй показывает стоимость неизвестного до того, как оно попадёт в опубликованный совет. Через несколько таких проходов журнал становится не бюрократией, а памятью технического решения.
Проверяемые источники
- W3C PROV-DM: The PROV Data Model — версия: W3C Recommendation, 30 April 2013, dated immutable publication. PROV-DM используется как vocabulary для inspection activity и связанных с ней document/note entities в журнале. Граница: Recommendation не даёт evidence quality score и не предписывает порядок редакционного решения.
- RFC 9110: HTTP Semantics, §8.8 validator fields — версия: RFC 9110, June 2022, immutable RFC publication. RFC 9110 позволяет точно назвать validator как свойство selected representation, а не как универсальную версию публикации. Граница: Стандарт HTTP не является источником compatibility или product behaviour вне конкретного protocol statement.
- W3C Verifiable Credentials Data Model v2.0 — версия: W3C Recommendation, 15 May 2025, dated immutable publication. W3C document фиксирует, что cryptographic verification не означает проверку truth закодированного claim; этим ограничен разбор signed evidence. Граница: Никакая VC-схема не запускается в fixture и не проверяет реальные credentials.