rbrooks/Quest-Board

Watch

Fork 0

Wiki merge drafts silently append instead of merging, and the draft gives no sign the GM-only text is kept #1195

New issue

Closed

opened 2026-10-14 19:26:26 +00:00 by claude-bot · 1 comment

claude-bot commented

2026-10-14 19:26:26 +00:00

Collaborator

Reported by the owner on prod, 14 Oct 2026, while merging a session's proposed page into an existing wiki page.

What happened

The "merge" was a plain append. The draft held the page's text with the session's paragraph pasted under it word for word, not woven in.
- Worker log: llama.cpp returned empty content (finish_reason='length', completion_tokens 2048), then merge_lore_entry_body LLM call failed …; falling back to append.
- merge_lore_entry_body (app/services/audio_service.py) caps the reply at max_tokens=2048. The model (Gemma 4) spent all of it thinking, so the visible answer was empty.
- Every other wiki rewrite there uses max_tokens=None, the setting the endpoint needs for prose.
- On failure the merge falls back to existing + "\n\n" + new without telling anyone, and the draft is marked ready as if it had merged.
The GM-only text looked dropped. By design the draft is the table's view (draft_service._table_view), and approving puts every GM block back where it was (wiki_text.merge_edit).
- Nothing on the draft screen says so, so the GM sees their note missing.
- On this page the draft was then saved again with a GM-block opener and no closing marker. Approving it is refused with a 422 ("The block that starts on line 1 is never closed"), so the page is safe.

Fix

Backend. merge_lore_entry_body uses max_tokens=None. On the draft path, a failed or empty merge fails the draft with a plain reason, so the GM can start it over, instead of passing off an append as a merge. The direct proposal-approval fallback in lore_service keeps its logged append (#287).
Draft screen. When the page has GM-only text, one line beside the draft says it is kept and goes back on approve. The wording goes through the Wording Review page first.

No wiki text from the owner's campaign is quoted here.

Reported by the owner on prod, 14 Oct 2026, while merging a session's proposed page into an existing wiki page. ## What happened 1. **The "merge" was a plain append.** The draft held the page's text with the session's paragraph pasted under it word for word, not woven in. - Worker log: `llama.cpp returned empty content (finish_reason='length', completion_tokens 2048)`, then `merge_lore_entry_body LLM call failed …; falling back to append`. - `merge_lore_entry_body` (`app/services/audio_service.py`) caps the reply at `max_tokens=2048`. The model (Gemma 4) spent all of it thinking, so the visible answer was empty. - Every other wiki rewrite there uses `max_tokens=None`, the setting the endpoint needs for prose. - On failure the merge falls back to `existing + "\n\n" + new` without telling anyone, and the draft is marked **ready** as if it had merged. 2. **The GM-only text looked dropped.** By design the draft is the table's view (`draft_service._table_view`), and approving puts every GM block back where it was (`wiki_text.merge_edit`). - Nothing on the draft screen says so, so the GM sees their note missing. - On this page the draft was then saved again with a GM-block opener and no closing marker. Approving it is refused with a 422 ("The block that starts on line 1 is never closed"), so the page is safe. ## Fix - **Backend.** `merge_lore_entry_body` uses `max_tokens=None`. On the draft path, a failed or empty merge **fails the draft** with a plain reason, so the GM can start it over, instead of passing off an append as a merge. The direct proposal-approval fallback in `lore_service` keeps its logged append (#287). - **Draft screen.** When the page has GM-only text, one line beside the draft says it is kept and goes back on approve. The wording goes through the Wording Review page first. No wiki text from the owner's campaign is quoted here.

claude-bot referenced this issue

2026-10-14 19:29:16 +00:00

fix(wiki): a merge draft merges or fails, never a silent append (#1195) #1196

rbrooks referenced this issue from a commit

2026-10-14 19:29:16 +00:00

fix(wiki): a merge draft merges or fails, never a silent append (#1195)

rbrooks referenced this issue from a commit

2026-10-14 19:29:16 +00:00

tests: ruff format (#1195)

claude-bot referenced this issue from a commit

2026-10-14 20:15:48 +00:00

Merge PR #1196: a merge draft merges or fails, never a silent append (#1195)

claude-bot referenced this issue

2026-10-14 20:16:04 +00:00

chore(release): v4.5.3-rc1 #1197

claude-bot referenced this issue

2026-10-14 20:24:59 +00:00

feat(wiki): a draft says the page's GM-only text is kept (#1195) #1198

rbrooks referenced this issue from a commit

2026-10-14 20:25:00 +00:00

feat(wiki): a draft says the page's GM-only text is kept (#1195)

claude-bot referenced this issue from a commit

2026-10-14 20:54:34 +00:00

Merge PR #1198: a draft says the page's GM-only text is kept (#1195)

claude-bot referenced this issue

2026-10-14 21:25:39 +00:00

chore(release): v4.5.3 #1199

claude-bot commented

2026-10-14 22:15:15 +00:00

Author

Collaborator

Done, and on prod in v4.5.3 (deployed 14 Oct, 5:14 pm Central, on the owner's say).

PR #1196, the merge.

merge_lore_entry_body is uncapped (max_tokens=None).
The draft path passes fallback_append=False, so a failed or empty merge marks the draft failed with the page untouched.
The direct proposal approval keeps its logged append (#287).

PR #1198, the draft screen. When the page has GM-only text, the draft says "Your GM-only text isn't shown here. It stays on the page when you approve." That's the owner's wording, Wording Review row e-001.

Checked.

On dev (4.5.3-rc1), the new merge was run against the live model with invented text. It returned one rewritten page in 18 s, not an append.
On prod: version 4.5.3, /ready OK, every service healthy, and the bot handshake OK. A backup was taken first.

A draft made before the fix still holds the old appended text, so it should be thrown away and the merge started again.

Done, and on prod in **v4.5.3** (deployed 14 Oct, 5:14 pm Central, on the owner's say). **PR #1196, the merge.** - `merge_lore_entry_body` is uncapped (`max_tokens=None`). - The draft path passes `fallback_append=False`, so a failed or empty merge marks the draft **failed** with the page untouched. - The direct proposal approval keeps its logged append (#287). **PR #1198, the draft screen.** When the page has GM-only text, the draft says "Your GM-only text isn't shown here. It stays on the page when you approve." That's the owner's wording, Wording Review row e-001. **Checked.** - On dev (4.5.3-rc1), the new merge was run against the live model with invented text. It returned one rewritten page in 18 s, not an append. - On prod: version 4.5.3, `/ready` OK, every service healthy, and the bot handshake OK. A backup was taken first. A draft made before the fix still holds the old appended text, so it should be thrown away and the merge started again.

claude-bot closed this issue

2026-10-14 22:15:23 +00:00