[Backend] Wiki suggestions ignore GM corrections and table-note labels

claude-bot commented

2026-09-11 21:42:00 +00:00

Collaborator

Finding

Wiki suggestions (lore proposals) see none of the event-level corrections from #424 or #607.

They don't re-run after corrections.
- They generate once, automatically, on first processing (summary_events._FIRST_TIME_ONLY).
- After that they run only from "Look for wiki updates again" on the session page.
- Regenerate and restore fire the fan-out with first_time=False, which skips them deliberately. So after corrections, the pending suggestions still date from the original run. On dev's replay session they are from 09-09, before every summary fix since #566.
They read the transcript, not the events. The input is the stored summary as one leading chunk, then the raw transcript segment by segment (chunk_transcript_for_extraction). They never read session_beats, so strikes, rewrites, table-note labels (#596) and relabels (#607) are invisible to them.
Re-running replaces only pending suggestions. create_bot_lore_proposals deletes the session's still-pending bot rows. Approved entries are left alone.

What this looks like on the replay session:

The GM's slip becomes a place. "Ironroot Hold" is proposed as a settlement the party arrived at, although the owner rewrote those events. A re-run today would read the corrected summary, but also the transcript, which still contains the slip.
Table chatter becomes lore:
- "Titanic … cover story utilized by Robert Ballard"
- "Ancient Greeks"
- "Civilized Society"

Options

Nudge (small). When the summary has been regenerated since suggestions were made, show "Your corrections changed this summary since wiki suggestions were made. Look again?" beside the button. On its own this does not fix Ironroot.
Feed the corrections to extraction (the real fix).
- Give each chunk a "GM corrections, which override the transcript" block, built from rewritten and struck events (original text, then corrected text).
- Drop or mark transcript segments that only table-note events cite.
- Measure on the replay session. Ironroot Hold and the chatter entries should go, and Theo, Harrowhark and the circus should stay.
Both.

Waiting for the owner to choose. The doubled-suggestions bug, filed alongside this, should be fixed first, or every re-run will keep writing duplicates.

## Finding Wiki suggestions (lore proposals) see none of the event-level corrections from #424 or #607. - **They don't re-run after corrections.** - They generate once, automatically, on first processing (`summary_events._FIRST_TIME_ONLY`). - After that they run only from **"Look for wiki updates again"** on the session page. - Regenerate and restore fire the fan-out with `first_time=False`, which skips them deliberately. So after corrections, the pending suggestions still date from the original run. On dev's replay session they are from 09-09, before every summary fix since #566. - **They read the transcript, not the events.** The input is the stored summary as one leading chunk, then the **raw transcript** segment by segment (`chunk_transcript_for_extraction`). They never read `session_beats`, so strikes, rewrites, table-note labels (#596) and relabels (#607) are invisible to them. - **Re-running replaces only pending suggestions.** `create_bot_lore_proposals` deletes the session's still-pending bot rows. Approved entries are left alone. What this looks like on the replay session: - **The GM's slip becomes a place.** "Ironroot Hold" is proposed as a settlement the party arrived at, although the owner rewrote those events. A re-run today would read the corrected summary, but also the transcript, which still contains the slip. - **Table chatter becomes lore:** - "Titanic … cover story utilized by Robert Ballard" - "Ancient Greeks" - "Civilized Society" ## Options 1. **Nudge (small).** When the summary has been regenerated since suggestions were made, show "Your corrections changed this summary since wiki suggestions were made. Look again?" beside the button. On its own this does not fix Ironroot. 2. **Feed the corrections to extraction (the real fix).** - Give each chunk a "GM corrections, which override the transcript" block, built from rewritten and struck events (original text, then corrected text). - Drop or mark transcript segments that only table-note events cite. - Measure on the replay session. Ironroot Hold and the chatter entries should go, and Theo, Harrowhark and the circus should stay. 3. **Both.** Waiting for the owner to choose. The doubled-suggestions bug, filed alongside this, should be fixed first, or every re-run will keep writing duplicates.

claude-bot added the

backend

enhancement

labels

2026-09-11 21:42:18 +00:00

claude-bot referenced this issue

2026-09-11 22:23:09 +00:00

[Backend] Wiki suggestions are written twice: the consolidate step's wait-retry is caught and retried again #609

claude-bot commented

2026-09-11 22:23:17 +00:00

Author

Collaborator

Owner's decision: hold until approved, and clear on changes

Chosen over the nudge. The reasoning: suggestions built from an uncorrected summary and transcript risk putting things in the wiki that didn't happen, so they should not exist until the GM has signed off on the content.

What changes

Generation moves to approval. generate_lore_proposals comes out of summary_events._FIRST_TIME_ONLY, and approve_session_content fires it instead — only when the session has no suggestions yet (lore_generation_status is None), so an approve/withdraw/approve cycle with no edits doesn't pay for a second extraction.
Corrections clear them. on_session_summary_available(..., first_time=False) is the single funnel for regenerate, restore and hand-edit, so clearing there covers all three: delete the session's still-pending bot suggestions and reset lore_generation_status to NULL, which returns the button to "Suggest wiki updates".
The manual button is unchanged. A GM who wants suggestions before approving still presses it.

Notes

Approved suggestions are already real wiki entries (proposed_by_bot false), so a clear can never touch them. It discards only untriaged suggestions — which is exactly what pressing the button again already does.
On prod, 3 of 12 sessions with a summary are approved. Under this change the other 9 produce no suggestions until approved or asked for. That is the intended trade: approval now also means "the wiki may learn from this".
Depends on #609. Without it, each generation still writes every suggestion twice.

Building both on fix/609-610-wiki-suggestions.

## Owner's decision: hold until approved, and clear on changes Chosen over the nudge. The reasoning: suggestions built from an uncorrected summary and transcript risk putting things in the wiki that didn't happen, so they should not exist until the GM has signed off on the content. ### What changes - **Generation moves to approval.** `generate_lore_proposals` comes out of `summary_events._FIRST_TIME_ONLY`, and `approve_session_content` fires it instead — only when the session has no suggestions yet (`lore_generation_status is None`), so an approve/withdraw/approve cycle with no edits doesn't pay for a second extraction. - **Corrections clear them.** `on_session_summary_available(..., first_time=False)` is the single funnel for regenerate, restore and hand-edit, so clearing there covers all three: delete the session's still-pending bot suggestions and reset `lore_generation_status` to NULL, which returns the button to "Suggest wiki updates". - **The manual button is unchanged.** A GM who wants suggestions before approving still presses it. ### Notes - Approved suggestions are already real wiki entries (`proposed_by_bot` false), so a clear can never touch them. It discards only untriaged suggestions — which is exactly what pressing the button again already does. - **On prod, 3 of 12 sessions with a summary are approved.** Under this change the other 9 produce no suggestions until approved or asked for. That is the intended trade: approval now also means "the wiki may learn from this". - Depends on #609. Without it, each generation still writes every suggestion twice. Building both on `fix/609-610-wiki-suggestions`.

rbrooks referenced this issue from a commit

2026-09-11 22:59:06 +00:00

fix(webapp): stop double-writing wiki suggestions, hold them for GM approval (#609, #610)

claude-bot referenced this issue

2026-09-11 23:00:31 +00:00

fix(webapp): stop double-writing wiki suggestions, and hold them for GM approval (#609, #610) #611

claude-bot commented

2026-09-11 23:00:44 +00:00

Author

Collaborator

Known gap left open by PR #611

clear_wiki_suggestions resets the session's lore state, but it cannot stop a run that is already in flight. A GM who regenerates the summary while extraction or matching is still going gets the pending suggestions cleared and the status reset, and then the running pipeline finishes and writes a fresh set built from the pre-correction summary — with the status going back to ready.

The window is narrow: it needs a regenerate during an active multi-pass run. The outcome is also no worse than the behaviour before #611, where suggestions predating corrections simply stayed forever. But it does leave a hole in the guarantee this issue is about.

Closing it properly wants a generation epoch, not a bigger delete: stamp the run with the summary it started from (or a counter bumped by every clear), and have lore_consolidate_proposals drop its results when the stamp no longer matches. That is the same shape as the row-lock check #609 added, and it belongs with a follow-up rather than being bolted onto this change.

Worth doing if the owner ever hits it in practice. Until then it is recorded, not scheduled.

## Known gap left open by PR #611 `clear_wiki_suggestions` resets the session's lore state, but it cannot stop a run that is **already in flight**. A GM who regenerates the summary while extraction or matching is still going gets the pending suggestions cleared and the status reset, and then the running pipeline finishes and writes a fresh set built from the pre-correction summary — with the status going back to `ready`. The window is narrow: it needs a regenerate during an active multi-pass run. The outcome is also no worse than the behaviour before #611, where suggestions predating corrections simply stayed forever. But it does leave a hole in the guarantee this issue is about. **Closing it properly wants a generation epoch**, not a bigger delete: stamp the run with the summary it started from (or a counter bumped by every clear), and have `lore_consolidate_proposals` drop its results when the stamp no longer matches. That is the same shape as the row-lock check #609 added, and it belongs with a follow-up rather than being bolted onto this change. Worth doing if the owner ever hits it in practice. Until then it is recorded, not scheduled.

claude-bot referenced this issue from a commit

2026-09-11 23:16:39 +00:00

Merge pull request 'fix(webapp): stop double-writing wiki suggestions, and hold them for GM approval (#609, #610)' (#611) from fix/609-610-wiki-suggestions into main

claude-bot commented

2026-09-11 23:21:35 +00:00

Author

Collaborator

Implemented in PR #611, merged as e2e6616 and deployed to dev.

Verified live on dev:

first_time=True : update_campaign_storyline, generate_journal_entry,
                  generate_session_title_suggestions, send_recap_email
first_time=False: update_campaign_storyline, generate_journal_entry,
                  generate_session_title_suggestions, clear_wiki_suggestions
clear task registered: True
approve queues generation: True

So wiki-suggestion generation has left the first-time fan-out entirely, a correction now fires clear_wiki_suggestions, and approval is what starts extraction.

What a GM sees now:

A newly transcribed session shows no wiki-suggestion state at all until they approve the summary or press "Suggest wiki updates".
Approving starts extraction once.
Any regenerate, restore or summary edit discards the untriaged suggestions and returns the button to "Suggest wiki updates". Approved wiki entries are untouched.

Closing. The in-flight race is recorded in the comment above and is not scheduled; reopen or file a follow-up if it is ever hit in practice.

Implemented in PR #611, merged as `e2e6616` and deployed to dev. **Verified live on dev:** ``` first_time=True : update_campaign_storyline, generate_journal_entry, generate_session_title_suggestions, send_recap_email first_time=False: update_campaign_storyline, generate_journal_entry, generate_session_title_suggestions, clear_wiki_suggestions clear task registered: True approve queues generation: True ``` So wiki-suggestion generation has left the first-time fan-out entirely, a correction now fires `clear_wiki_suggestions`, and approval is what starts extraction. **What a GM sees now:** - A newly transcribed session shows no wiki-suggestion state at all until they approve the summary or press "Suggest wiki updates". - Approving starts extraction once. - Any regenerate, restore or summary edit discards the untriaged suggestions and returns the button to "Suggest wiki updates". Approved wiki entries are untouched. Closing. The in-flight race is recorded in the comment above and is not scheduled; reopen or file a follow-up if it is ever hit in practice.

claude-bot closed this issue

2026-09-11 23:22:00 +00:00

rbrooks referenced this issue from a commit

2026-09-11 23:46:58 +00:00

chore(release): v4.4.0

claude-bot referenced this issue

2026-09-11 23:47:14 +00:00

chore(release): v4.4.0 #612