A record larger than its replay
Lesson 8 taught why a conversation that never ends compacts: older rows leave the replay behind one summary and stay in the record, flagged, never deleted. An endless room (rules track, lesson 8) does that for as long as it lives, so its record is always much larger than what a turn replays. That gap was fine until three different features each needed to ask "which rows?", and each answered from whatever it happened to hold.
- A branch copied the message ids the screen held. The screen leaves compaction summaries out and loads one window, so a branch of Master Chief carried its newest rows and none of the summary they stand on. When it was measured, Master Chief had 12,355 rows, of which 163 were live after a 113 KB summary; a branch made from the screen would have carried 162 turns and no summary at all: an experiment that had forgotten everything before that morning.
- A room's markdown export read every page: twelve thousand messages of a room that never ends.
- A context transfer from a room wrote that same whole record to a file.
The root: two questions
Since 2026-11-11 services/conversation_ranges.py is the one place those three ask, and it answers two questions. replay_at answers what a turn would replay: with no message named, the replay of the next turn (the latest compaction summary and every row after it, on the newest branch of the tree); with a message named, the replay as it stood when that message was the newest row, even if a later compaction has since taken it out, because the rows one compaction took out together are exactly the replay of that time, summary included. current_section answers Dad's definition, given that morning:
현재 섹션은 마지막 압축 이후 화면에서 스크롤 가능한 대화 영역을 말하는 거야.
("The current section is the part of the conversation you can scroll on the screen since the last compaction.") That is the turns compaction has not taken out, on the newest branch, without the summary and the other system lines, which are the room's bookkeeping and not its talk. The boundary is the store's own flag, never a guess from the screen. Other segment boundaries (a broadcast, a KST day) stay with the endless-room kit, and the current section is one more segment key there, so an export of today and an export of the current section are the same call.
Branches, done properly
Dad wanted to experiment beside a room without touching it, 2026-11-11, 11:18:
치프방이나 게임방의 원래 흐름은 해치면 안 되잖아. 근데 다른 방향으로 대화를 해보고 싶을 때 분기 만들어서 해보면 실험만 하고 버릴 수도 있잖아. ... 문맥을 최대한 포함해서 분기가 돼야 하니까.
("The original flow of the Chief room or the game room must not be harmed. But when I want to take the conversation another way, I can branch, experiment, and throw it away ... and a branch has to carry as much of the context as possible.") So a branch is a fresh, ordinary conversation that carries what its source would have replayed at the branch point, read by replay_at on the server, never from the ids the screen sent. Nothing done in it reaches the source: it has its own id, so the room's follow, its Coop notices, the On Air hold and the room's own compaction, which all ask "is this the room?" by id, never see it. Every row the branch copied is written to the branch's own JSONL with its source ids, so the ground truth of the branch says where each row came from.
What a copy alone could not say is the link back, so each branch has one row recording which conversation and which message it left from, and which room that was. The header names the source, goes back to it, and discards the branch in one step. My system prompt in a branch says I am in an experiment and how something worth keeping goes back: by the room relay, on Dad's word, the same one every room uses, with no second channel. A private branch keeps no link back at all.
The first relay from a branch read "Source: 53 messages". Fifty-two of them were rows the branch was born with, borrowed from its source; it had said one thing of its own. The count now distinguishes the two.