> /manual-test-plan is running…

⏺ I’ll analyze the changes and generate a manual test plan. Let me first examine the code changes in detail.

...

⏺ Write(.claude/test-plans/2025-12-02-stat-advancements-mod-system.md)
  ⎿  Wrote 185 lines to .claude/test-plans/2025-12-02-stat-advancements-mod-system.md
     # Test Plan: Stat Advancements Using Mod System
     Generated: 2025-12-02
     ## Overview
     This PR changes how stat advancements are applied to fighters. Instead of mutating the fighter’s override fields directly, stat advancements now use
     the mod system that is computed at display time. This should make the stat improvements visible in the statline while keeping the underlying fighter
     data clean.
...

⏺ I’ve created a comprehensive manual test plan at .claude/test-plans/2025-12-02-stat-advancements-mod-system.md.

  Summary of the test plan:

  [ ... table ...]

  The test plan covers:
  - Core functionality: New stat advancements using the mod system
  - Stacking: Multiple advancements on the same stat
  - Visual indicators: Modified stat tooltips and highlights
  - Backward compatibility: Legacy advancements continue to work
  - Performance: No N+1 query regression
  - Edge cases: Distance format stats (Movement with inch marks)

  The test plan is accessible at http://localhost:8000/_debug/test-plans/ when the dev server is running.

## Overview

This PR changes how stat advancements are applied to fighters. Instead of mutating the fighter’s override fields directly, stat advancements now use the mod system that is computed at display time. This should make the stat improvements visible in the statline while keeping the underlying fighter data clean.

## Setup

1. Navigate to http://localhost:8000
2. Log in to a test account
3. You need a **campaign list** with at least one fighter that has XP to spend (minimum 10 XP)
   - If you don’t have one, create a new list, attach it to a campaign, and give a fighter some XP

## Test 1: Apply a Stat Advancement (New Mod System)

**Purpose**: Verify that new stat advancements use the mod system and display correctly.

Steps:
1. Navigate to http://localhost:8000/lists/
2. Find a list that is attached to a campaign (look for campaign name badge)
3. Click on the list to view it
4. Find a fighter with XP available (look for “XP” badge showing current XP)
5. Note the fighter’s current stat values in the statline (e.g., WS, BS, M, S, T, etc.)
6. Click on the fighter card to expand details, or click the fighter’s name to go to the detail page
7. Find and click the “Advancements” link/button
8. Click “+ Add Advancement”
9. Choose to “Spend XP” (not roll dice)
10. Select “Characteristic” as the advancement type
11. Choose a stat to advance (e.g., “Weapon Skill” or “Movement”)
12. Note the XP cost and cost increase shown
13. Click “Confirm” to apply the advancement

**Verify**:
- [ ] The advancement appears in the advancements table with type “Stat”
- [ ] The XP shown in “Current XP” has been reduced by the XP cost
- [ ] Navigate back to the list view and check the fighter’s statline
- [ ] The improved stat should show the new value (e.g., WS “3+” becomes “2+”, or M ‘4”’ becomes ‘5”’)
- [ ] The improved stat should have a tooltip indicating it’s modified (hover over the stat value)
- [ ] The stat value should have a yellow/warning background highlight

## Test 4: Archiving Removes Advancement Effect

**Purpose**: Verify that archiving a fighter removes the advancement’s effect from display.

**Note**: This test verifies that archived advancements are excluded from the mod calculation. Currently, archiving advancements directly may not be exposed in the UI.

🧑‍💻 **Human Action Required**
To test this, please run the following in the Django shell:
```bash
manage shell
```

Then run:
```python
from gyrinx.core.models import ListFighterAdvancement

# Find the most recent stat advancement
adv = ListFighterAdvancement.objects.filter(advancement_type=’stat’, uses_mod_system=True).order_by(’-created’).first()
print(f”Advancement: {adv}”)
print(f”Fighter: {adv.fighter}”)
print(f”Stat: {adv.stat_increased}”)

# Archive it
adv.archived = True
adv.save()
print(”Advancement archived”)
```

After archiving:
1. Navigate to the fighter’s list view
2. Check the statline

**Verify**:
- [ ] The stat that was advanced should revert to its previous value (or show one less improvement if multiple advancements exist)
- [ ] The modification indicator should update accordingly

🧑‍💻 **Human Action Required**
To restore the advancement after testing:
```python
adv.archived = False
adv.save()
print(”Advancement restored”)
```

---
description: Generate a manual test plan for code changes, formatted for Claude for Chrome
argument-hint: [short-name]
---

# Manual Test Plan Generator

You are helping generate a manual test plan for recent code changes. The test plan will be executed by Claude for Chrome, which can:
- View and interact with web pages
- Click buttons, fill forms, check checkboxes
- Navigate between pages
- Verify visual content on screen

Claude for Chrome CANNOT:
- Run terminal commands or access local files
- Access the codebase directly
- Make purchases or access financial sites without confirmation

## Your Task

Analyze the recent code changes and generate a manual test plan that can be executed in a browser.

**First, check what has changed:**

!`git diff main --name-only | head -20`

!`git log main..HEAD --oneline | head -10`

## Instructions for Generating the Test Plan

Based on the changes above, create a test plan with these sections:

### 1. Prerequisites
- What pages/URLs need to be visited
- What test data needs to exist (e.g., “a list with fighters”, “a campaign”)
- Any setup steps the tester needs to do first

### 2. Test Cases
For each test case, provide:
- **Name**: Brief description
- **Steps**: Numbered list of exact UI actions (click, type, select, etc.)
- **Expected Result**: What should be visible on screen after the action

### 3. Format Requirements

Format the test plan so Claude for Chrome can execute it step-by-step:

- Use explicit UI element descriptions (e.g., “Click the ‘Delete’ button next to the equipment name”)
- Include what to look for to verify success (e.g., “The credits value in the header should increase from X to Y”)
- Note any checkboxes or form fields to interact with
- Specify page navigation clearly (e.g., “Navigate to the fighter’s detail page by clicking on their name”)

### 4. Human Assistance Required

Some tests may require actions outside the browser that Claude for Chrome cannot perform. For these, include a **”🧑‍💻 Human Action Required”** section that instructs Claude for Chrome clearly to stop and ask the user to help.

Examples of when to ask for human help:
- Running CLI commands (e.g., `python manage.py ...`, `git ...`)
- Checking database state
- Modifying environment variables or settings
- Restarting servers
- Checking log files
- Any action requiring terminal access

Format these as:
```
🧑‍💻 **Human Action Required**
STOP HERE and ask the user to perform the following action.

Run this command and tell me the result:
`python manage.py shell -c “print(MyModel.objects.count())”`
```

### 5. Context: This Application

This is Gyrinx, a list-building application for tabletop gaming. Key concepts:
- **Lists**: Collections of fighters and equipment
- **Fighters**: Characters with stats and equipment
- **Equipment**: Items assigned to fighters (weapons, wargear)
- **Campaign Mode**: Lists attached to campaigns track credits (currency)
- **List Building Mode**: Lists not attached to campaigns (no credits)
- **Rating**: Total cost of all fighters and equipment in a list
- **Stash**: Equipment held in reserve (separate from rating)
- **Refunds**: In campaign mode, removing items can optionally refund credits

### 6. Output Format and File Saving

Structure your output as a numbered checklist that Claude for Chrome can follow.

**IMPORTANT**: After generating the test plan, you MUST save it to a file using the Write tool:
- Directory: `.claude/test-plans/`
- Filename format: `YYYY-MM-DD-short-name.md` where short-name comes from:
  - The argument provided to this command: `$ARGUMENTS`
  - If no argument, derive from the current git branch name (sanitized)
- Create the directory if it doesn’t exist: `!mkdir -p .claude/test-plans`

Example filename: `2025-11-30-removal-handlers.md`

The test plan will then be accessible at `http://localhost:8000/_debug/test-plans/` when the Django dev server is running.

### Test Plan Template

```markdown
# Test Plan: [Feature/Change Name]

Generated: [Date]
Branch: [Branch name]

## Setup
1. Navigate to [URL]
2. Ensure you have [prerequisites]

## Test 1: [Test Name]
**Purpose**: [What this tests]

Steps:
1. [Action to take]
2. [Action to take]
3. [Action to take]

**Verify**:
- [ ] [Expected visual result]
- [ ] [Expected visual result]

## Test 2: [Test Name]
...

## Test N: [Test requiring CLI/terminal]
**Purpose**: [What this tests]

🧑‍💻 **Human Action Required**
This test requires terminal access. Please:
1. Run: `[command]`
2. Tell me the output

Then I will verify: [what to check]
```

Now analyze the changes shown above, generate the test plan, and save it to a file.