Resolution Decision: решение о решениях

После появления конфликта (CR) обычно возникает бытовая реакция: «надо договориться» или «надо поправить формулировку».

Эти действия могут быть полезны, но они не отвечают на практический вопрос, который должен уметь решать любой управляемый контур:

какие из конфликтующих решений продолжают действовать после фиксации конфликта — и на каких условиях?

Пока этот вопрос не имеет объекта ответа, система остаётся в неопределённости. Она знает, что конфликт существует, но не знает, что теперь считать действующим поведением.

Разрешение конфликта — отдельная сущность

Conflict Record (CR) фиксирует факт несовместимости: одновременно действовать так и так нельзя.

Resolution Decision (RD) возвращает определённость: оно задаёт, как именно система должна интерпретировать действие решений, участвующих в конфликте.

Это не «новое общее решение вместо старых».
Это решение о решениях.

Ключевой признак RD: оно всегда ссылается на конкретный CR.
Без этой ссылки любое «разрешение» превращается в произвольное изменение состояния решений без причины в модели.

RD ≠ документ

Документ — носитель текста, который можно улучшать и редактировать.

RD — акт выбора, который меняет картину действующих решений относительно зафиксированного конфликта.

Критерий различия простой:
документ можно переписать, не изменив действующее поведение; RD изменяет действующее поведение даже без изменения текста конфликтующих решений.

Если подменить RD документом, ломается следующее:

устранение конфликта начинает выглядеть как «переписали описание»;
исчезает связь с CR: непонятно, какой именно конфликт был снят;
нельзя восстановить причинность: почему действие решений изменилось именно так;
невозможно проверить, что система стала определённой, а не просто получила новый текст.

Документ может хранить RD. Он не является RD по смыслу.

RD ≠ обсуждение

Обсуждение производит аргументы, варианты и согласование. Оно может быть долгим и дробиться по каналам.

RD — это фиксированный выбор, который завершает неопределённость по конкретному CR.

Критерий различия:
обсуждение отвечает на вопрос «какое решение лучше», RD отвечает на вопрос «какие решения теперь действуют и как именно».

Если подменить RD обсуждением, ломается следующее:

конфликт может считаться «решённым», хотя действующие решения остаются несовместимыми;
появляется иллюзия определённости: «мы всё обсудили», но система всё ещё не знает, что делать;
невозможно отличить разговор от изменения действующего поведения;
повторяемость исчезает: то же обсуждение приходится проводить заново, потому что итог не существует как объект.

RD — не часть дискуссии. RD — результат, который задаёт действие.

RD как решение, действующее во времени

Решения в серии уже введены как действующие объекты. RD не исключение.

RD можно рассматривать как Decision Record (DR) с определённой ролью: он не вводит новое правило поведения напрямую, а управляет действием других решений в зоне конфликта.

Минимальные условия существования RD — как объекта, а не как «полей записи»:

1) Привязка к конфликту

RD существует только как ответ на конкретный CR.
Эта привязка отделяет «разрешение конфликта» от произвольной отмены решений.

2) Определение статуса действия решений

RD фиксирует, что именно происходит с действием решений, участвующих в конфликте:

что вытесняется;
что продолжает действовать;
что продолжает действовать, но с ограничениями.

Это не «мнение о правильности», а изменение допустимого поведения системы.

3) Момент, с которого действует разрешение

RD задаёт, с какого момента конфликт считается снятым данным способом.
Это нужно не для отчётности, а для причинности: чтобы не смешивать «когда решили» и «когда стало допустимо действовать так».

Этого достаточно, чтобы RD был управляемым объектом, а не пояснением задним числом.

Минимальная структура RD как записи и зачем элементы нужны системе

Если RD фиксируется как артефакт, его структура должна быть минимальной и функциональной.
Она не должна превращать RD в спецификацию внедрения.

Минимально:

Ссылка на CR

Нужна, чтобы разрешение не было «безадресным».
Система должна знать, какой конфликт стал определённым.

Перечень затронутых решений

Нужен, чтобы было ясно, чьё действие меняется именно этим RD.
RD не может быть «про всё»; он всегда про конкретные участники конфликта.

Правило интерпретации действия

Нужно, чтобы система могла вывести определённость:

какие решения считаются вытесненными;
какие — продолжают действовать;
какие — действуют только при указанных ограничениях.

Это ядро RD: не текст, а изменение картины действия.

Момент вступления в силу

Нужен, чтобы отделить историю конфликтности от истории разрешения.

Другие элементы (детальные статусы, метрики, теги) не усиливают сущность RD. Они относятся к реализации.

Ограничения и следствия модели

RD не делает конфликт «ошибкой».
CR фиксирует несовместимость, RD фиксирует выбор, как жить с этой несовместимостью.

Отсюда следуют ограничения.

Что становится невозможным при неверной модели

Если «разрешение конфликта» не является отдельной сущностью, становится невозможным:

доказать, что конфликт был снят, а не замят;
восстановить, какое действие считалось допустимым после конфликта;
отличить «мы переписали решение» от «мы изменили статус его действия»;
удерживать причинность: какой CR был разрешён каким выбором.

В итоге конфликт либо растворяется в переписке, либо превращается в неявную отмену решений.

Что становится прозрачным при корректной модели

Если RD существует как решение о решениях, становится прозрачным:

какой именно CR стал определённым;
какие решения вытеснены и почему это не переписывает историю их принятия;
какие решения продолжают действовать и в какой части;
где определённость восстановлена, а где конфликт остаётся открытым.

RD возвращает системе способность однозначно выводить допустимое действие — но делает это через управление действием решений, а не через их «исправление».

Следующий вопрос

До этого момента DR, CCR, CR и RD рассматривались как будто они существуют в одном общем пространстве.

Это допущение скрывает ключевую неопределённость: где именно действует решение, где именно произошла смена контекста, и где именно конфликт вообще является конфликтом.

Если область действия не зафиксирована, система не может ответить на базовые вопросы:

относится ли DR к этой части системы или к другой;
применим ли CCR к данному набору решений;
локален ли CR или конфликтует «всё со всем»;
где RD изменяет картину действующих решений, а где оно не имеет силы.

Следующий шаг формализации неизбежен: у любой записи должен появиться параметр области действия.