changelog

## Phase 1: Parse Arguments Read the argument for the target version or sprint number. If a version is given, use the corresponding git tag. If a sprint number is given, use the sprint date range. Verify the repository is initialized: run `git rev-parse --is-inside-work-tree` to confirm git is available. If not a git repo, inform the user and abort gracefully. --- ## Phase 2: Gather Change Data Read the git log since the last tag or release: ``` git log --oneline [last-tag]..HEAD ``` If no tags exist, read the full log or a reasonable recent range (last 100 commits). Read sprint reports from `production/sprints/` for the relevant period to understand planned work and context behind changes. Read completed design documents from `design/gdd/` for any new features implemented during this period. --- ## Phase 3: Categorize Changes Categorize every change into one of these categories: - **New Features**: Entirely new gameplay systems, modes, or content - **Improvements**: Enhancements to existing features, UX improvements, performance gains - **Bug Fixes**: Corrections to broken behavior - **Balance Changes**: Tuning of gameplay values, difficulty, economy - **Known Issues**: Issues the team is aware of but have not yet resolved - **Miscellaneous**: Changes that do not fit the above categories, or commits whose messages are too vague to classify confidently For each commit, check whether the message contains a task ID or story reference (e.g. `[STORY-123]`, `TR-`, `#...