Unidentified items: GM-reviewed model prompts still get the true name, and proposals about one don't match its page #993

New issue

Closed

opened 2026-10-01 17:09:29 +00:00 by claude-bot · 1 comment

claude-bot commented

2026-10-01 17:09:29 +00:00

Collaborator

Two follow-ups from #877's audit of where a wiki page's title is read. Neither is a leak to a player by itself; both were left out of #877 because they change prompt plumbing in reminder_tasks.

1. Prompts whose output a GM reviews are given the true title.

The draft tools (draft_service.start_*), where current_title is also the title an approval writes back.
The relationship-proposal prompt (tasks/reminder_tasks.py, near the entity list), which by design also includes GM-only page titles.

The output waits for a GM, so nothing reaches a player unreviewed. But the model can write an unidentified item's true name into text meant for the table, and a GM can miss it. Fix: give the prompt table_title for an unidentified page and keep the true current_title only for the write-back.

2. A proposal about an unidentified item arrives as a new page.
_entry_entity_keys matches the model's proposals to existing pages by true title and aliases, but the model is shown the party's name (player_title). So a proposal about "the dull iron ring" doesn't match the page whose true title is something else, and is offered as a new page instead of an update. Fix: add the table's title to the keys an unidentified page matches on.

Also noted, left as it is: the audit log's descriptions (trash, restore, version restore, purge) carry true titles. It is administrators-only, and an administrator can read the database anyway.

tests/wiki/test_title_readers.py (from #877) lists the reads involved; update its allowlist reasons when these change.

Refs #877.

Two follow-ups from #877's audit of where a wiki page's title is read. Neither is a leak to a player by itself; both were left out of #877 because they change prompt plumbing in `reminder_tasks`. **1. Prompts whose output a GM reviews are given the true title.** - The draft tools (`draft_service.start_*`), where `current_title` is also the title an approval writes back. - The relationship-proposal prompt (`tasks/reminder_tasks.py`, near the entity list), which by design also includes GM-only page titles. The output waits for a GM, so nothing reaches a player unreviewed. But the model can write an unidentified item's true name into text meant for the table, and a GM can miss it. **Fix:** give the prompt `table_title` for an unidentified page and keep the true `current_title` only for the write-back. **2. A proposal about an unidentified item arrives as a new page.** `_entry_entity_keys` matches the model's proposals to existing pages by true title and aliases, but the model is shown the party's name (`player_title`). So a proposal about "the dull iron ring" doesn't match the page whose true title is something else, and is offered as a new page instead of an update. **Fix:** add the table's title to the keys an unidentified page matches on. **Also noted, left as it is:** the audit log's descriptions (trash, restore, version restore, purge) carry true titles. It is administrators-only, and an administrator can read the database anyway. `tests/wiki/test_title_readers.py` (from #877) lists the reads involved; update its allowlist reasons when these change. Refs #877.

claude-bot referenced this issue

2026-10-01 17:34:56 +00:00

An unidentified item keeps its party name outside the wiki (#877) #994

claude-bot referenced this issue

2026-10-01 18:01:37 +00:00

An unidentified item's true name can reach players through title reads outside the wiki #877

claude-bot commented

2026-10-01 18:55:44 +00:00

Author

Collaborator

Picking this up (1 Oct), on fix/993-unidentified-prompts. Both parts: the model is shown an unidentified page's table name while the true title is kept only for write-back, and an unidentified page also matches a proposal on its table name (an ambiguous table name is treated as no match rather than guessed). An approved update must not rename or identify the page.

Picking this up (1 Oct), on `fix/993-unidentified-prompts`. Both parts: the model is shown an unidentified page's table name while the true title is kept only for write-back, and an unidentified page also matches a proposal on its table name (an ambiguous table name is treated as no match rather than guessed). An approved update must not rename or identify the page.