# Research: Edit Combatant

**Feature**: 004-edit-combatant
**Date**: 2026-03-03

## Research Summary

No unknowns or NEEDS CLARIFICATION items exist in the spec or technical context. The feature follows well-established patterns already present in the codebase.

## Decision: Domain Function Pattern

**Decision**: Follow the identical pattern used by `addCombatant` and `removeCombatant` — pure function returning `EditCombatantSuccess | DomainError`.

**Rationale**: Consistency with existing code. All three existing domain operations use the same signature shape `(encounter, ...args) => { encounter, events } | DomainError`. No reason to deviate.

**Alternatives considered**: None — the pattern is well-established and fits perfectly.

## Decision: Event Shape

**Decision**: `CombatantUpdated` event includes `combatantId`, `oldName`, and `newName` fields.

**Rationale**: Including both old and new name enables downstream consumers (logging, undo, UI feedback) without needing to diff state. Follows the pattern of `CombatantRemoved` which includes `name` for context.

**Alternatives considered**: Including only `newName` — rejected because losing the old name makes undo/logging harder with no storage savings.

## Decision: Name Validation

**Decision**: Reuse the same validation logic as `addCombatant` (reject empty and whitespace-only strings, same error code `"invalid-name"`).

**Rationale**: Consistent user experience. The spec explicitly states this assumption.

**Alternatives considered**: None — spec is explicit.

## Decision: UI Mechanism

**Decision**: Minimal inline edit — clicking a combatant name makes it editable via an input field, confirmed on blur or Enter.

**Rationale**: Simplest interaction that meets FR-007 without adding modals or prompts. Follows MVP baseline.

**Alternatives considered**: Modal dialog, browser `prompt()` — both rejected as heavier than needed for MVP.