1.9 KiB
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.