Границы по файлам не спасают от расхождения интерфейса: две пчелы, разные файлы, сломанная сборка

[gHashTag]

Часть #1090.

Что случилось

Две пчелы работали параллельно с непересекающимися границами:

• Королева открывает PR в текущую ветку, и её слияния дерутся с работой человека #1110 — rings/SR-02/QueenBranchCommitter.swift
• Ревьюер видит только диф, поэтому не может судить критерий про целое #1109 — rings/SR-00/QueenReviewVerdictRequest.swift, rings/SR-02/ChatViewModel.swift

#1110 сделала baseBranch() возвращающим String? — именно то, что требовал критерий: если ветка по умолчанию не определяется, PR не открывать. Место вызова находится в ChatViewModel.swift, то есть в границе другой пчелы. Обе поступили правильно, ни одна границу не нарушила, сборка сломана:

rings/SR-02/ChatViewModel.swift:4142: error: value of optional type 'String?'
must be unwrapped to a value of type 'String'

Что это значит

Правило одного владельца на путь защищает от конфликта записи. От конфликта интерфейса оно не защищает вообще: смена сигнатуры в своём файле ломает чужой, и заметить это может только сборка, которой в цикле пчелы нет.

Это станет обычным делом ровно по мере того, как параллельность начнёт работать.

Возможные направления

• Собирать объединённое состояние перед приёмкой, а не только каждую ветку отдельно.
• Считать смену публичной сигнатуры особым случаем: такая задача не идёт параллельно с задачами, чьи границы содержат вызовы.
• Разрешать пчеле правку чужого файла, если она вынуждена изменением своего, но помечать это явно.

Выбор направления — часть задачи; ни одно не очевидно.

Готово, когда

• Параллельный прогон двух задач, одна из которых меняет сигнатуру, а вторая владеет вызовом, не оставляет дерево несобирающимся.
• Проверка ломается, если вернуть прежнее поведение.

Что уже сделано

Новый файл: чистое правило, решающее, расходятся ли две ветки по интерфейсу.
Сам сторож уже есть — runInterfaceDivergenceWatchdog в ChatViewModel
собирает объединённое дерево перед приёмкой, и первое из трёх направлений
выше тем самым закрыто. Не закрыт второй критерий: drift-guard судит
рассогласование между двумя времянками, которые строит сам, а не между двумя
состояниями ЭТОГО дерева, поэтому возврат прежнего поведения его не двигает.

Правило выносится в SR-00 отдельным файлом, потому что там оно проверяемо
однофайловым набором и не требует трогать ChatViewModel, которым владеют
другие задачи.

Границы

• rings/SR-00/QueenInterfaceDivergence.swift

[gHashTag]

Measured 2026-08-23: the first of the three directions is already built, and what is missing is the proof.

QueenBranchCommitter.verifyCombinedBuild(branches:baseRef:) exists and is wired: before acceptance the Queen narrows to the lanes that actually contribute (queen.combined.narrowed), builds the combined tree, and returns either a CombinedBuildProof or a refusal carrying the build summary. An empty combination is treated as nothing-to-find rather than a failure, so a fresh swarm's first acceptance is not blocked.

So the interface-divergence hazard this issue describes is caught at acceptance today. What this issue's own criteria ask for - a parallel run where one task changes a signature and another owns the call, and a check that breaks if the old behaviour returns - has no run behind it that I can find.

This issue is skipped by the Queen every pass because it has no ## Границы section, so it can never be delegated as it stands. A boundary that matches what is left would be:

## Границы

`rings/SR-02/QueenBranchCommitter.swift`

with criteria along these lines:

• A drill plants two branches: one changes a public signature in file A, the other calls it from file B, each inside its own boundary.
• The combined build refuses that pair, and the refusal names the compiler error rather than restating the event.
• The same drill passes when the second branch is updated to the new signature.
• The check breaks if the combined build is skipped: removing the call makes the drill fail.
• Proven by a run, with the journal lines quoted in the pull request.

I am not editing the issue body - the words are yours. If you paste that boundary section in, the Queen can pick it up on the next pass with budget.

[gHashTag]

Queue hygiene: Queen reports this task as accepted and the work as already landed. Closing the tracking issue removes a completed candidate from every future scheduling round.

[gHashTag]

Queue hygiene: Queen reports this task as accepted and the work as already landed. Closing the tracking issue removes a completed candidate from every future scheduling round.