Files
initiative/specs/004-edit-combatant/research.md

41 lines
1.9 KiB
Markdown

# 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.