Campaign supports multiple GMs (replace single gm_id) #2

New issue

Open

opened 2026-08-04 02:09:58 +00:00 by ginjiruu · 0 comments

ginjiruu commented

2026-08-04 02:09:58 +00:00

Owner

A campaign can have more than one GM (see CONTEXT.md, "GM"), but the write model
stores a single gm_id — in the campaigns table, the Campaign aggregate, and
every EventData payload.

Change it to carry a set of GMs:

Schema: campaigns.gm_id → a GM list (e.g. gm_ids_json, mirroring the
existing players_json).
EventData.GMID / Campaign.GMID → a GM collection.
The UI and HATEOAS action list: GM actions (can_manage, can_delete,
can_leave exclusion) must resolve for any of the GMs.
Migration for existing rows (promote the single gm_id into a one-element set).

The FGA gm: [adventurer] relation already supports this; only the write model
and projections lag.

A campaign can have more than one GM (see CONTEXT.md, "GM"), but the write model stores a single `gm_id` — in the `campaigns` table, the `Campaign` aggregate, and every `EventData` payload. Change it to carry a set of GMs: - Schema: `campaigns.gm_id` → a GM list (e.g. `gm_ids_json`, mirroring the existing `players_json`). - `EventData.GMID` / `Campaign.GMID` → a GM collection. - The UI and HATEOAS action list: GM actions (`can_manage`, `can_delete`, `can_leave` exclusion) must resolve for any of the GMs. - Migration for existing rows (promote the single gm_id into a one-element set). The FGA `gm: [adventurer]` relation already supports this; only the write model and projections lag.

ginjiruu added the

ready-for-agent

label

2026-08-04 02:10:02 +00:00