Решили: боевую четвёрку помечает поле на слоте ростера (RosterSlot.InBattle), а не порядок
первых четырёх элементов массива. Старые сейвы с ростером из четырёх читаются молча: записанные
слоты становятся боевыми, остальные места — пустыми, версия схемы не двигается. Статистика «Сосуда»
(боёв, побед, смертей, урона) живёт счётчиками на VesselState.
Почему: отряд вырос с четырёх мест до восьми, из которых в бой выходят четверо
(дизайн §2.1), и признака «кто выходит» в коде не было вовсе
— GuildRoster.Build отправлял в бой весь run.Guild.
- Порядок вместо поля отвергнут: он дешевле и не заводит второго владельца факта, но делает перестановку в ленте семантической. Игрок тянет человека на другое место, чтобы поменять двоих местами, — а получает вывод из боя. Экран, где одно и то же движение значит две разные вещи в зависимости от индекса, объяснить нельзя.
- Миграция схемы отвергнута: расширение массива и новое
boolполе читаются старым сейвом без потерь —InBattleу записанных слотов проставляется при загрузке. Поднимать версию значит писать миграцию и держать тесты на обе, ради факта, который выводится из длины массива. - Агрегат по Летописи отвергнут: Летопись пишет подвиги, а не каждый бой (procedural-lore), поэтому счётчики из неё не собираются без того, чтобы начать писать туда рядовые бои — а это ровно то, от чего Летопись защищали.
Сказано: «Поле на слоте InBattle», «Читаем и расширяем молча», «Счётчики на VesselState» (22.08.2026, сессия 216679c6, ответы на вопросы §9 ТЗ).
Грабли: число открытых мест — состояние забега, а не конфига: вместимость сверх шести
открывается наградой внутри забега и сгорает вместе с ним (ГД-решение 2026-08-22/9). GameConfig
держит только базу и потолок; экран, читающий вместимость из конфига, покажет чужое число.
Владелец правды: Scripts/Guild/RunState.cs, Scripts/Game/Flow/GuildRoster.cs,
ТЗ Planning - Preparation Screens §3.1 и §9.