Lore entry summaries are never generated except by the manual endpoint (docstring claims otherwise) #285

New issue

Closed

opened 2026-08-05 20:33:04 +00:00 by claude-bot · 0 comments

claude-bot commented

2026-08-05 20:33:04 +00:00

Contributor

Found in the LLM trigger audit that produced #278 and #279. Verified against the code, not inferred.

The bug

generate_lore_entry_summary (webapp/backend/app/tasks/reminder_tasks.py:3179) has exactly one enqueue site in the whole codebase:

webapp/backend/app/routers/campaigns.py:3287
    generate_lore_entry_summary.delay(str(entry_id))

That is POST /campaigns/{id}/lore/{entry_id}/regenerate-summary — a manual, GM-initiated action.

Its own docstring (reminder_tasks.py:3182-3183) says:

Triggered after body changes (via the regenerate-summary endpoint) or after a new entry is created with a non-empty body.

The second trigger does not exist.

Consequence

Every lore entry created by any automated path has summary = NULL and will never get one unless a GM manually clicks regenerate on it, one entry at a time. That covers:

entries created by approving a bot proposal (campaigns.py:2746 → lore_service.create_lore_entry)
shelf promotion stubs (shelf_service.py:1101)
canonical-name auto-created entries (sessions.py:326)

Since bot proposals are the main way the wiki gets populated after a session, this is most entries.

Fix direction

Either wire it into lore_service.create_lore_entry / update_lore_entry / the proposal-approval path so the docstring becomes true, or correct the docstring and accept it as manual-only. The first is almost certainly what was intended — the summary field exists to give wiki entries a one-line gloss, and having it populated only on entries someone happened to click is close to useless.

If wiring it up: fire on create-with-body and on body change, and guard against re-firing when the body is unchanged. Note the task already no-ops when the LLM is unconfigured (:3218-3223, log + return, no state written).

Acceptance

Entries created via proposal approval, shelf promotion, and canonical-name auto-create get a summary
Docstring matches reality either way
Test covering at least the proposal-approval path

Labels: backend

Found in the LLM trigger audit that produced #278 and #279. Verified against the code, not inferred. ## The bug `generate_lore_entry_summary` (`webapp/backend/app/tasks/reminder_tasks.py:3179`) has **exactly one enqueue site** in the whole codebase: ``` webapp/backend/app/routers/campaigns.py:3287 generate_lore_entry_summary.delay(str(entry_id)) ``` That is `POST /campaigns/{id}/lore/{entry_id}/regenerate-summary` — a manual, GM-initiated action. Its own docstring (`reminder_tasks.py:3182-3183`) says: > Triggered after body changes (via the regenerate-summary endpoint) **or after a new entry is created with a non-empty body.** The second trigger does not exist. ## Consequence Every lore entry created by any automated path has `summary = NULL` and will never get one unless a GM manually clicks regenerate on it, one entry at a time. That covers: - entries created by approving a bot proposal (`campaigns.py:2746` → `lore_service.create_lore_entry`) - shelf promotion stubs (`shelf_service.py:1101`) - canonical-name auto-created entries (`sessions.py:326`) Since bot proposals are the *main* way the wiki gets populated after a session, this is most entries. ## Fix direction Either wire it into `lore_service.create_lore_entry` / `update_lore_entry` / the proposal-approval path so the docstring becomes true, **or** correct the docstring and accept it as manual-only. The first is almost certainly what was intended — the summary field exists to give wiki entries a one-line gloss, and having it populated only on entries someone happened to click is close to useless. If wiring it up: fire on create-with-body and on body change, and guard against re-firing when the body is unchanged. Note the task already no-ops when the LLM is unconfigured (`:3218-3223`, log + return, no state written). ## Acceptance - [ ] Entries created via proposal approval, shelf promotion, and canonical-name auto-create get a summary - [ ] Docstring matches reality either way - [ ] Test covering at least the proposal-approval path Labels: backend

claude-bot added the

backend

bug

labels

2026-08-05 20:34:19 +00:00