docs: fill journeydoc tutorial prose

docs/tutorials/admin/01-configure-game-system.md

@@ -1,35 +1,62 @@
 ---
 sidebar_position: 1
 title: Configure the game system (skills, items, conditions, backgrounds)
-description: Step-by-step guide to configuring the game system (skills, items, conditions, backgrounds).
+description: Build the LARP rule engine — abilities, effects, skills, items, conditions — that every character is scored against.
 ---
 
 # Configure the game system (skills, items, conditions, backgrounds)
 
-Step-by-step guide to configuring the game system (skills, items, conditions, backgrounds).
+A *game system* in Larping is the rule engine: the abilities characters are scored on, the effects that modify those abilities, and the catalogue of skills, items, and conditions that carry those effects. Set this up once per LARP setting; players then pick from it when they build characters.
 
 ## Goal
 
-`{{TODO: write the goal — what the reader can do after this tutorial}}`
+By the end the game system will have its abilities defined, at least one effect on each, and a starter catalogue of skills, items, and conditions players can pick from. Characters built against this system will compute stats correctly.
 
 ## Prerequisites
 
-`{{TODO: list prerequisites — app installed, OpenRegister configured, access level, prior tutorials}}`
+- The **Larping** and **OpenRegister** apps installed and enabled with the Larping register imported (see [Manage Larping settings](03-admin-settings.md)).
+- Admin (or the game master role on this Larping instance) — defining the rule engine is an administrative act that shapes every character built afterwards.
+- A clear picture of the LARP system's rules — which abilities scores exist, what skills modify them, what equipment players can carry.
 
 ## Steps
 
-`{{TODO: numbered steps; one screenshot per step under /screenshots/tutorials/admin/01-configure-game-system-<step>.png}}`
+1. Start with **Abilities** (under **Game settings** in the Larping navigation, or via **Abilities** directly). Add the ability scores your system uses — *Strength*, *Health*, *Mana*, *XP*, whatever the LARP rules call out. Each ability gets a name, an optional description, and a base value.
+
+   ![Abilities list with rule-system entries](/screenshots/tutorials/admin/01-configure-game-system-01.png)
+
+2. Move to **Effects**. An effect is the atomic modifier — `+2 to Strength`, `-1 to Health`. Add one effect per atomic rule the system needs. Pick the **abilities** it targets, set the **modifier** (an integer), and decide whether it is **cumulative** (applies again every time it is reached) or one-shot.
+
+   ![Effects list with example modifiers](/screenshots/tutorials/admin/01-configure-game-system-02.png)
+
+3. Build the **Skills** catalogue. Each skill carries one or more effects, an **xpCost**, and a prerequisite list — required other skills, required ability thresholds, required conditions. Players pay XP to attach a skill; the stat engine applies its effects when the character recalculates.
+
+   ![Skills list with effects attached](/screenshots/tutorials/admin/01-configure-game-system-03.png)
+
+4. Build the **Items** and **Conditions** catalogues the same way. Items are equipment with effects; the **unique** flag locks them to a single character. Conditions are status effects (poisoned, blessed, exhausted) with the same `unique` option. Both reference the effects you defined in step 2.
+
+   ![Items and conditions catalogues](/screenshots/tutorials/admin/01-configure-game-system-04.png)
+
+5. Open **Events** and create the events your LARP runs (date range, location). Attach post-event effects — `+10 XP for participation`, `Battle Scar condition for the losing side` — that will apply to participating characters after the event closes (see [Subscribe to an event](../user/06-event-subscription.md)).
+
+   ![Events with post-event effects](/screenshots/tutorials/admin/01-configure-game-system-05.png)
 
 ## Verification
 
-`{{TODO: how the reader confirms they're done}}`
+The catalogues populate: **Abilities**, **Effects**, **Skills**, **Items**, **Conditions** all have entries. A new test character can attach a skill, the stat engine recalculates, the ability values reflect the effect's modifier, and the audit trail names the source. The deterministic order — skills → items → conditions → events — produces the result your rule book expects.
 
 ## Common issues
 
 | Symptom | Fix |
 |---|---|
-| `{{TODO: a likely issue}}` | `{{TODO: fix}}` |
+| Skill saved but attaching it does nothing | The skill has no effects, or its effects target no abilities — open the skill and add an effect with at least one target ability and a non-zero modifier. |
+| Ability score doesn't go negative when expected | `allowed_negative` is currently not enforced by the stat engine; sum of modifiers will produce whatever value it produces. Documented in the RPG-system reference. |
+| Same effect counted twice on the character | Mark the effect non-`cumulative` so it applies only once even when reached via multiple skills/items. |
+| Players can't see new entries | Browser cache — players reload the app; the catalogue reads through OpenRegister live, no further config needed server-side. |
+| Screenshots may be missing | App not yet installed in the test environment; rerun `npm run test:e2e:docs` once it is. |
 
 ## Reference
 
-`{{TODO: links to feature reference / architecture pages}}`
+- [Game mechanics reference](../../features/game-mechanics.md) — abilities, effects, skills, items, conditions.
+- [RPG system reference](../../features/rpg-system.md) — the stat-calculation pipeline.
+- [Manage Larping settings](03-admin-settings.md) — register / schema mapping the catalogues depend on.
+- [Subscribe to an event](../user/06-event-subscription.md) — how events feed back into character progression.

docs/tutorials/admin/02-approve-players.md

@@ -1,35 +1,62 @@
 ---
 sidebar_position: 2
 title: Approve characters and manage players
-description: Step-by-step guide to approving characters and managing players.
+description: Review a player's character background, approve it for play, link the player record to the character, and roll up post-event effects.
 ---
 
 # Approve characters and manage players
 
-Step-by-step guide to approving characters and managing players.
+Players submit characters with backgrounds; game masters review, ask for changes, and approve. Once approved, the character can participate in events and accumulate XP. The game master also maintains the **Players** catalogue — the real-world person behind each character — and applies post-event effects to keep the world consistent across sessions.
 
 ## Goal
 
-`{{TODO: write the goal — what the reader can do after this tutorial}}`
+By the end you will have reviewed a submitted character, flipped its `approved` flag, ensured the player record is linked, and walked through how post-event effects apply to keep player progression in sync.
 
 ## Prerequisites
 
-`{{TODO: list prerequisites — app installed, OpenRegister configured, access level, prior tutorials}}`
+- The Larping game system is configured (see [Configure the game system](01-configure-game-system.md)).
+- One or more players have submitted characters (see [Create a character](../user/02-create-character.md)).
+- Admin or game-master role on this Larping instance.
 
 ## Steps
 
-`{{TODO: numbered steps; one screenshot per step under /screenshots/tutorials/admin/02-approve-players-<step>.png}}`
+1. Open the **Players** list from the Larping navigation. Each entry is a real-world person who plays in the LARP — name, description, contact. Add players who aren't there yet via **Add Item**.
+
+   ![Players list](/screenshots/tutorials/admin/02-approve-players-01.png)
+
+2. Open the **Characters** list and filter to characters with `approved = false`. These are the submissions waiting for game-master review.
+
+   ![Characters list filtered to unapproved](/screenshots/tutorials/admin/02-approve-players-02.png)
+
+3. Open a character. Read the **background** field on the **Properties** tab. Check the **Relations** tab to make sure the **player** link (`ocName` on the character) points at the right **Player** record — if not, fix it now (this is how post-event effects find the right player at scoring time).
+
+   ![Character detail with background story](/screenshots/tutorials/admin/02-approve-players-03.png)
+
+4. Flip the **approved** field to `true` and save. The character is now allowed to participate in events. The audit trail records the approval, who approved it, and when.
+
+   ![Approval flipped to true on the character](/screenshots/tutorials/admin/02-approve-players-04.png)
+
+5. After an event, open the event and apply its post-event effects to participating characters. The effects flow through the stat engine on the **events** layer — XP awarded, items granted, conditions inflicted. Each character's audit trail picks up `Event: …` entries for the changes.
+
+   ![Post-event effects applied across the roster](/screenshots/tutorials/admin/02-approve-players-05.png)
 
 ## Verification
 
-`{{TODO: how the reader confirms they're done}}`
+Approved characters carry `approved = true` and an audit-trail entry showing who flipped them. Each character has a populated player link. After post-event scoring, the participating characters' ability values reflect the awarded XP / items / conditions, and the audit trail names the event as the source.
 
 ## Common issues
 
 | Symptom | Fix |
 |---|---|
-| `{{TODO: a likely issue}}` | `{{TODO: fix}}` |
+| Approved characters still flagged as unapproved in lists | Browser cache or stale list — refresh; the dashboard's *Recent characters* widget may also need a manual refresh. |
+| Post-event effects don't reach a character | The character's player link is empty or wrong, so the event-effect application can't match the character. Fix the `ocName` (player UUID) on the character. |
+| Two characters belong to the same player | That's allowed — one **Player** can have many **Characters**. Each character carries its own approval state and stat history. |
+| Approval check disappeared from character form | The `approved` field is part of the `character` schema; if it's missing the schema import is incomplete — see [Manage Larping settings](03-admin-settings.md). |
+| Screenshots may be missing | App not yet installed in the test environment; rerun `npm run test:e2e:docs` once it is. |
 
 ## Reference
 
-`{{TODO: links to feature reference / architecture pages}}`
+- [Create a character](../user/02-create-character.md) — the player-facing side of the workflow.
+- [Subscribe to an event](../user/06-event-subscription.md) — where post-event effects come from.
+- [Character management reference](../../features/character-management.md) — the `approved` field and the player link.
+- [Events and Players reference](../../features/events-players.md) — the post-event effect flow.

docs/tutorials/admin/03-admin-settings.md

@@ -1,35 +1,62 @@
 ---
 sidebar_position: 3
 title: Manage Larping settings
-description: Step-by-step guide to managing Larping settings.
+description: Pick the data source (Nextcloud DB or OpenRegister) for each of the 9 entity types, set the register / schema mappings, and save.
 ---
 
 # Manage Larping settings
 
-Step-by-step guide to managing Larping settings.
+Larping's admin settings page lives in the Nextcloud administration panel and does one job: it tells Larping where each of its 9 entity types (ability, character, condition, effect, event, item, player, setting, skill) is stored — in Nextcloud's built-in database or in OpenRegister. The recommended setup is OpenRegister for everything; the internal option exists for tight installs that can't run OpenRegister.
 
 ## Goal
 
-`{{TODO: write the goal — what the reader can do after this tutorial}}`
+By the end every entity type will have a data-source set, the OpenRegister-backed ones will have a register and schema picked, and the Larping app's lists and **Add Item** dialogs will work end to end.
 
 ## Prerequisites
 
-`{{TODO: list prerequisites — app installed, OpenRegister configured, access level, prior tutorials}}`
+- Admin on the Nextcloud instance.
+- The **OpenRegister** app installed and enabled, with at least one register available — Larping's installer ships a default `larpingapp_register.json` that auto-imports on install/upgrade, so a fresh install usually already has the right register and schemas.
+- A view on which entities you actually want under OpenRegister (the default is *all of them*).
 
 ## Steps
 
-`{{TODO: numbered steps; one screenshot per step under /screenshots/tutorials/admin/03-admin-settings-<step>.png}}`
+1. Go to **Settings → Administration → Larping**. The page lists the 9 entity types as rows.
+
+   ![Larping admin settings page](/screenshots/tutorials/admin/03-admin-settings-01.png)
+
+2. For each entity type, pick the **data source** — **Internal** (Nextcloud's database via Entity/Mapper) or **Open Register** (JSON object storage with schema validation). Internal is fine for small installs that don't want OpenRegister; Open Register is the recommended choice and unlocks audit trails, cross-object relations, and search.
+
+   ![Per-entity data-source picker](/screenshots/tutorials/admin/03-admin-settings-02.png)
+
+3. For each row set to **Open Register**, pick the **register** from the dropdown. The schema dropdown filters to schemas on the chosen register. Pick the matching schema — `character` for the character row, `ability` for the ability row, and so on. The default Larping register ships these named correctly so the pairing is mechanical.
+
+   ![Register and schema mapping per entity](/screenshots/tutorials/admin/03-admin-settings-03.png)
+
+4. Click **Save All** to persist. The page reloads with the saved selections; the config keys (`register`, `character_schema`, `player_schema`, `ability_schema`, `skill_schema`, `item_schema`, `condition_schema`, `effect_schema`, `event_schema`, `setting_schema`) land under the `larpingapp` app in Nextcloud's `IAppConfig`.
+
+   ![Settings saved confirmation](/screenshots/tutorials/admin/03-admin-settings-04.png)
+
+5. Open the Larping app and confirm: the **Characters**, **Items**, **Events**, **Skills**, **Conditions** lists load, and **Add Item** on each opens a dialog with real form fields. If you switched a row from Internal to Open Register, existing data is *not* migrated automatically — pre-existing internal rows stay where they were; new entries land in the configured source.
+
+   ![Larping lists working after the mapping](/screenshots/tutorials/admin/03-admin-settings-05.png)
 
 ## Verification
 
-`{{TODO: how the reader confirms they're done}}`
+Each entity row shows its chosen data source; OpenRegister rows show the register and schema they map to. The Larping app loads its lists without an error banner. **Add Item** on a list opens a dialog with the schema's form fields populated. The audit trail on a newly-created character records the creation.
 
 ## Common issues
 
 | Symptom | Fix |
 |---|---|
-| `{{TODO: a likely issue}}` | `{{TODO: fix}}` |
+| Schema dropdown is empty for a row | The register you picked has no matching schema — either pick a different register (the default Larping register ships every schema) or run the `larpingapp_register.json` re-import from the OpenRegister side. |
+| Larping lists work but **Add Item** dialog is empty | The schema mapping is set but the schema is empty (no fields) — re-import the Larping register configuration. |
+| Saved settings revert on reload | The save call failed; check the Nextcloud log for a 4xx/5xx on `POST /apps/larpingapp/api/settings`. |
+| Mixing Internal + Open Register breaks cross-entity relations | Relations between entities (character → skills, skills → effects) only resolve when both ends are in the same source. Pick one or the other for the whole chain. |
+| Screenshots may be missing | App not yet installed in the test environment; rerun `npm run test:e2e:docs` once it is. |
 
 ## Reference
 
-`{{TODO: links to feature reference / architecture pages}}`
+- [Admin settings reference](../../features/admin-settings.md) — config keys, API endpoints, the underlying services.
+- [Open Larping for the first time](../user/01-first-launch.md) — the user-facing check that the mapping works.
+- [Configure the game system](01-configure-game-system.md) — what to do once the mapping is in place.
+- [Register config JSON reference](../../features/register-config-json.md) — the `larpingapp_register.json` import.