[Backend+Frontend] Pronouns for players, and pronouns shown wherever a person or character is named

claude-bot commented

2026-09-15 16:45:28 +00:00

Collaborator

Context

The owner asked for this in the round-two design feedback (#363) and marked it as needed: pronoun fields for players, player characters and NPCs.

What exists today (checked 2026-09-15)

NPCs and PCs as wiki articles. lore_entries.pronouns exists, and is also on versions and drafts. Articles of type npc and player_character have a pronouns field on the new-entry, edit, proposal and draft-review forms. The article shows it in its header and infobox (WikiArticle.jsx).
A member's characters. campaign_characters.pronouns exists and is edited and shown in the campaign page's member list. It is copied onto the character's article when the article has none (campaign_character_service.py), and it survives export and import.
Generated NPCs come with pronouns (generation_service.py).
Players themselves: nothing. users has display_name and display_name_override, but no pronouns.
Prompts. Only the journal-entry task gives the model any pronouns (generate_journal_entry in reminder_tasks.py). Even there it uses the legacy one-character-per-member CampaignMember.character_pronouns. The session summary, the event log and wiki suggestions are written with no pronouns for players, characters or NPCs.

The round-two mockups showed pronouns on one NPC only, so they looked missing. They mostly exist already. The gaps are:

a field for players,
showing all three consistently wherever a name appears,
giving them to the models that write about people.

Proposal

Player pronouns. Add an optional users.pronouns field: free text, up to 50 characters to match the character field, set on Profile and applying to the whole account. Offer she/her, he/him and they/them as suggestions, never as a fixed list. Show it next to the display name:
- in member lists
- in the "Are you in?" roster
- in attendance
- on transcript speaker labels
- on the party page
Show what already exists. In the rebuild (#366), put PC and NPC pronouns next to the name on every surface that draws a character:
- party-page members
- article headers
- hover previews
- cards and reveals at the table
Give them to the models.
- Include the pronouns for players, for every active character (from campaign_characters, not the legacy member field) and for the NPCs already in the context.
- Pass them to summary, event-extraction and wiki-suggestion prompts, not only the journal entry.
- Players are the speakers in a transcript, and out-of-character talk gets summarised too, so the model needs player pronouns as well as character pronouns.

Open questions

A per-campaign override for player pronouns, for someone who uses different ones in different groups? Leaning no: account-wide only, until someone asks.
Visibility: the same as the display name (fellow campaign members and the GM).
If campaign export carries member names, should it carry member pronouns too?

Out of scope

Discord embed content (v5.4.0).

Acceptance criteria

A player can set, change and clear their pronouns on Profile, and they appear next to their name on the roster surfaces above.
PC and NPC pronouns appear next to the name on the redesigned character surfaces.
The summary, event-log and wiki-suggestion prompts include the known pronouns, and a test asserts they are in the built prompt.
Account deletion removes player pronouns. They live on the user row, but confirm the deletion service does not copy them anywhere.

## Context The owner asked for this in the round-two design feedback (#363) and marked it as needed: pronoun fields for players, player characters and NPCs. ## What exists today (checked 2026-09-15) - **NPCs and PCs as wiki articles.** `lore_entries.pronouns` exists, and is also on versions and drafts. Articles of type `npc` and `player_character` have a pronouns field on the new-entry, edit, proposal and draft-review forms. The article shows it in its header and infobox (`WikiArticle.jsx`). - **A member's characters.** `campaign_characters.pronouns` exists and is edited and shown in the campaign page's member list. It is copied onto the character's article when the article has none (`campaign_character_service.py`), and it survives export and import. - **Generated NPCs** come with pronouns (`generation_service.py`). - **Players themselves: nothing.** `users` has `display_name` and `display_name_override`, but no pronouns. - **Prompts.** Only the journal-entry task gives the model any pronouns (`generate_journal_entry` in `reminder_tasks.py`). Even there it uses the legacy one-character-per-member `CampaignMember.character_pronouns`. The session summary, the event log and wiki suggestions are written with no pronouns for players, characters or NPCs. The round-two mockups showed pronouns on one NPC only, so they looked missing. They mostly exist already. The gaps are: 1. a field for players, 2. showing all three consistently wherever a name appears, 3. giving them to the models that write about people. ## Proposal 1. **Player pronouns.** Add an optional `users.pronouns` field: free text, up to 50 characters to match the character field, set on Profile and applying to the whole account. Offer she/her, he/him and they/them as suggestions, never as a fixed list. Show it next to the display name: - in member lists - in the "Are you in?" roster - in attendance - on transcript speaker labels - on the party page 2. **Show what already exists.** In the rebuild (#366), put PC and NPC pronouns next to the name on every surface that draws a character: - party-page members - article headers - hover previews - cards and reveals at the table 3. **Give them to the models.** - Include the pronouns for players, for every active character (from `campaign_characters`, not the legacy member field) and for the NPCs already in the context. - Pass them to summary, event-extraction and wiki-suggestion prompts, not only the journal entry. - Players are the speakers in a transcript, and out-of-character talk gets summarised too, so the model needs player pronouns as well as character pronouns. ## Open questions - A per-campaign override for player pronouns, for someone who uses different ones in different groups? Leaning no: account-wide only, until someone asks. - Visibility: the same as the display name (fellow campaign members and the GM). - If campaign export carries member names, should it carry member pronouns too? ## Out of scope - Discord embed content (v5.4.0). ## Acceptance criteria - A player can set, change and clear their pronouns on Profile, and they appear next to their name on the roster surfaces above. - PC and NPC pronouns appear next to the name on the redesigned character surfaces. - The summary, event-log and wiki-suggestion prompts include the known pronouns, and a test asserts they are in the built prompt. - Account deletion removes player pronouns. They live on the user row, but confirm the deletion service does not copy them anywhere.

claude-bot added the

backend

enhancement

frontend

labels

2026-09-15 16:45:47 +00:00

claude-bot referenced this issue

2026-09-15 16:45:59 +00:00

[UX] Full mockups with sample data — 3-5 directions for comparison #363

claude-bot referenced this issue

2026-09-15 18:21:00 +00:00

[UX] Redesign coverage: where every shipped and planned feature lives in Design A #656

claude-bot referenced this issue

2026-09-15 18:49:31 +00:00

v4.4.0 build order: UX Overhaul in six phases, with two review checkpoints #535

claude-bot referenced this issue

2026-09-16 02:05:54 +00:00

[UX] Mock up every catalogued surface, for players and GMs, before building #659

rbrooks referenced this issue from a commit

2026-09-16 02:32:37 +00:00

feat(feedback-site): lane 1 of the surface mockups — the shell (#659)

claude-bot referenced this issue

2026-09-16 02:32:52 +00:00

feat(feedback-site): lane 1 of the surface mockups — the shell (#659) #669

claude-bot referenced this issue

2026-09-16 02:49:13 +00:00

[UX] Mock up every catalogued surface, for players and GMs, before building #659

claude-bot commented

2026-09-16 02:49:28 +00:00

Author

Collaborator

What this looks like in the mockups (#659, lane 1)

Drawing the account menu turned up a concrete shape for this issue, and a mistake worth recording because of how easily it happened.

The mistake. My first draft showed Priya the pronouns he/him. Those are her character's — Ossian Vale is he/him; Priya is she/her. The shared mockup sample (tools/feedback-site/static/prototype/shared/data.js) only ever carried one pron field, on the party row, which reads as belonging to the character and sits on the same row as the player's name. So the wrong one was the easy one to reach for. That is a data-shape problem, not a slip, and the same shape exists in the app: lore_entries.pronouns and campaign_characters.pronouns are both about the fiction, and there is no player-level field at all.

The fix in the sample. playerPron is now a separate field from pron, and the two deliberately differ so that conflating them is visible immediately:

Player	Their pronouns	Character	Character's pronouns
Priya	she/her	Ossian Vale	he/him
Marcus	he/him	Wren Halloway	she/her
Tomás	he/him	Bastian Crowe	he/him
Ines	they/them	Nix Tallow	they/them
Ade	she/her	Sister Quill	she/her

The rule this implies for the rebuild. Any surface that names a person must say which set it is using, and must never let one stand in for the other. Two worked examples now drawn:

The account menu (SH-4) shows the signed-in person's own pronouns under their name — the one place someone is named to themselves.
A search result for a party member (SH-9) renders both, each beside whom it belongs to: "Wren Halloway · Druid 6 · she/her · played by Marcus (he/him)".

This also bears on prompt-building, which the issue already raises: a summariser handed "Marcus" and she/her because the character field was nearest will misgender a real person in generated prose that then gets saved as a recap. Worth treating the separation as a data-model requirement rather than a display nicety.

No code change to the app here — this is the mockup work (PR #669). Flagging it so whoever implements #653 starts from two fields, not one.

## What this looks like in the mockups (#659, lane 1) Drawing the account menu turned up a concrete shape for this issue, and a mistake worth recording because of how easily it happened. **The mistake.** My first draft showed Priya the pronouns **he/him**. Those are her *character's* — Ossian Vale is he/him; Priya is she/her. The shared mockup sample (`tools/feedback-site/static/prototype/shared/data.js`) only ever carried one `pron` field, on the party row, which reads as belonging to the character *and* sits on the same row as the player's name. So the wrong one was the easy one to reach for. That is a data-shape problem, not a slip, and the same shape exists in the app: `lore_entries.pronouns` and `campaign_characters.pronouns` are both about the fiction, and there is no player-level field at all. **The fix in the sample.** `playerPron` is now a separate field from `pron`, and the two deliberately differ so that conflating them is visible immediately: | Player | Their pronouns | Character | Character's pronouns | |---|---|---|---| | Priya | she/her | Ossian Vale | he/him | | Marcus | he/him | Wren Halloway | she/her | | Tomás | he/him | Bastian Crowe | he/him | | Ines | they/them | Nix Tallow | they/them | | Ade | she/her | Sister Quill | she/her | **The rule this implies for the rebuild.** Any surface that names a person must say which set it is using, and must never let one stand in for the other. Two worked examples now drawn: - The **account menu** (`SH-4`) shows the signed-in person's own pronouns under their name — the one place someone is named to themselves. - A **search result** for a party member (`SH-9`) renders both, each beside whom it belongs to: *"Wren Halloway · Druid 6 · she/her · played by Marcus (he/him)"*. This also bears on prompt-building, which the issue already raises: a summariser handed "Marcus" and `she/her` because the character field was nearest will misgender a real person in generated prose that then gets saved as a recap. Worth treating the separation as a data-model requirement rather than a display nicety. No code change to the app here — this is the mockup work (PR #669). Flagging it so whoever implements #653 starts from two fields, not one.

rbrooks referenced this issue from a commit

2026-09-22 04:51:12 +00:00

feat(backend): notifications, campaign search and the live endpoint (#727, #655)

rbrooks referenced this issue from a commit

2026-09-22 08:55:38 +00:00

feat(you): Profile in sections, Notifications as a grid, Plan & billing (#727, #642)

claude-bot referenced this issue

2026-09-23 06:43:14 +00:00

Lane 3: Members & characters (#729, CAMP-8) #768

claude-bot referenced this issue

2026-09-23 06:48:15 +00:00

Build lane 3: the campaign core and Settings (CAMP-1 to CAMP-17, SH-7) #729

claude-bot referenced this issue from a commit

2026-09-23 07:14:46 +00:00

feat(backend): a member's own pronouns, beside their name (IS-230, #729)

claude-bot referenced this issue

2026-10-01 19:01:30 +00:00

The writing models are given nobody's pronouns #999

claude-bot commented

2026-10-01 19:01:53 +00:00

Author

Collaborator

Closing, with the one unbuilt part moved to #999. Checked against main on 1 Oct.

Built. Players have users.pronouns (40 characters), set and cleared on Profile. It shows beside the name in the member list, the "Are you in?" roster, attendance, transcript speaker labels, the party page, the account menu and discussion posts. Characters' and NPCs' pronouns show in article headers, hover previews, and the table's cards and previews. The player's and the character's are separate fields everywhere (audience_service reads them apart), as this thread asked.

Not built: the models are given nobody's pronouns. The summary, event-extraction, wiki-suggestion and journal prompts carry none, and no test asserts they would. That is the part with real consequences (a saved recap that misgenders someone), so it has its own issue: #999, which also takes the account-deletion test and the export question.

Emails and the bot's posts carry no pronouns; Discord embeds were out of scope here.

Closing, with the one unbuilt part moved to #999. Checked against main on 1 Oct. **Built.** Players have `users.pronouns` (40 characters), set and cleared on Profile. It shows beside the name in the member list, the "Are you in?" roster, attendance, transcript speaker labels, the party page, the account menu and discussion posts. Characters' and NPCs' pronouns show in article headers, hover previews, and the table's cards and previews. The player's and the character's are separate fields everywhere (`audience_service` reads them apart), as this thread asked. **Not built: the models are given nobody's pronouns.** The summary, event-extraction, wiki-suggestion and journal prompts carry none, and no test asserts they would. That is the part with real consequences (a saved recap that misgenders someone), so it has its own issue: #999, which also takes the account-deletion test and the export question. Emails and the bot's posts carry no pronouns; Discord embeds were out of scope here.

claude-bot closed this issue

2026-10-01 19:02:14 +00:00

claude-bot referenced this issue

2026-10-01 21:57:23 +00:00

The writing models are told people's pronouns, players' and characters' apart (#999) #1013