Сценарий: почему обновление отделили от приёмки проекта?
Разработчик видит, что обновление Harness не проверяет завершённость STEP. Возникает естественный вопрос: это забытая проверка или сознательная граница ответственности? По одному текущему условию в коде ответить нельзя. Код показывает поведение; причины решения приходится восстанавливать по документам и истории.
Decision Archaeology помогает исследовать такие вопросы. Это чтение доказательств с ограниченным объёмом истории, явными выводами и пробелами. Результат не меняет архитектуру автоматически и не превращает правдоподобное объяснение модели в принятое решение.
От действующего контракта к ограниченной истории
Сначала закрепите ревизию репозитория и определите конкретный вопрос. Затем прочитайте относящиеся к нему принятые ADR, требования, принципы проекта и архитектурные документы. История Git дополняет эти источники: показывает последовательность изменений, но сама по себе не доказывает мотив автора.
Вопрос о конкретном решении + зафиксированная ревизия
↓
Принятые ADR / требования / принципы / архитектура
↓
Ограниченная история нужного файла в Git
↓
Полученные задачи и PR, подтверждающие обстоятельства
↓
Факты → выводы → противоречия → недостающие доказательстваРеальный пример запроса истории документа обновления в репозитории шаблона:
git rev-parse HEAD
git log -n 12 --format='%h %s' -- .harness/docs/UPDATES.md
git show 88755a0 -- .harness/docs/UPDATES.mdЭти команды читают историю, не запускают обновление и не изменяют проект. Двенадцать коммитов — граница этого примера, а не универсальное правило для любого исследования. Расширять область следует по конкретной недостающей связи.
Реальный пример: установка и исторические доказательства
В задаче о блокировке обновления зафиксирован исторический сбой: предварительная проверка проходила, а установка откатывалась из-за проверки старых доказательств завершения и производных документов проекта. Автор отдельно описал наблюдённое поведение, ограничения сохранённого вывода и синтетическое воспроизведение.
В коммите изменения границы обновления установка отделена от проверки рабочих артефактов. Сохранились проверка источника, правила владения файлами, слияние, журнал и откат. Действующий протокол обновления подтверждает эту границу: успешная установка служебного слоя не означает успешную приёмку STEP.
Здесь мы разбираем опубликованные доказательства. Воспроизведение из исторической задачи в рамках статьи заново не запускалось. Его наблюдения нельзя выдавать за результаты нашей проверки текущего проекта.
Что считать фактом, а что — инженерным выводом
Документированный факт
В задаче зарегистрирована блокировка установки из-за исторических проектных доказательств. Коммит и действующий протокол исключают приёмку продукта из условий установки.
Обоснованный вывод
Разделение позволяет обновить служебный слой до устранения несовместимости рабочих артефактов. Этот вывод объясняет связь источников, но не восстанавливает полный ход обсуждения автора.
Пробел в доказательствах
В этом разборе не приведён принятый ADR со списком отвергнутых альтернатив. Нельзя утверждать, что автор сравнил все возможные варианты или выбрал самый быстрый из них.
Граница уверенности
Исторический сбой не доказывает, что текущая установка содержит тот же дефект. Текущее поведение нужно проверять по действующим исходникам и проверкам.
В протоколе исследования используются признаки documented и inference, уровни уверенности и ссылки на доказательства. Гипотеза без доказательств допускает лишь низкую уверенность и явное указание пробела; она не может обосновать PASS.
Что делать с противоречиями между ADR и кодом
Если принятый ADR описывает одну границу, а код реализует другую, сохраните оба подтверждённых утверждения. Более поздняя дата коммита не отменяет ADR автоматически. Возможны отступление реализации, устаревший документ или ещё не оформленное изменение решения; одной хронологии недостаточно, чтобы выбрать объяснение.
Результат исследования фиксирует предполагаемое расхождение и недостающие доказательства. Новое устойчивое решение оформляется новым ADR, который явно заменяет прежнее. Исторический статус Accepted не переписывается задним числом на основании ответа модели.
Чат и память сессии не заменяют источники. Если PR или задача реально получены с сервера, на них можно ссылаться, сохраняя различие между внешним свидетельством и локально проверяемыми файлами Git.
Исследование причин не заменяет проверку изменения
Codebase Grounding отвечает, что работает сейчас и как связаны части системы. Decision Archaeology исследует, почему конкретное решение возникло. Анализ влияния отвечает на следующий вопрос: что может пострадать от предполагаемого изменения.
По итогам исторического разбора можно сформулировать ограничения для будущего плана: например, сохранить независимость установки от приёмки продукта и не ослаблять проверку источника. Сам разбор не разрешает менять код, расширять границы STEP, обходить проверки или считать гипотезу новым требованием.
Бюджеты чтения, точная ревизия и ограничение истории проверяются инструментами. Оценку смысла, конкурирующих объяснений и уверенности выполняет модель. Такая граница позволяет использовать историю как проверяемый материал, сохраняя видимыми сомнения и конфликты.
Источники и дальнейшее чтение
Протокол исследования инженерных решений · Контракт установки Harness. Связанные страницы: возможности архитектурного анализа, роль истории Git и граница между работой модели и детерминированными проверками.