Implement semantic versioning for frontend and backend

[trillium]

Overview

The project lacks a formal versioning strategy. Implement semantic versioning (semver) for both the frontend and backend packages to track releases and communicate the impact of changes.

Current State

• All three package.json files (root, backend, client) are at 0.3.0
• One ancient git tag: v0.2.0 from February 2020
• No GitHub releases, no CHANGELOG, no release tooling
• ~30% of recent commits follow conventional commit format — inconsistent across contributors
• No commitlint enforcement
• Deploys to AWS ECS via Docker, images tagged by git short SHA, manual workflow_dispatch

Action Items

Phase 1 — Foundation

• Install and configure changesets (best fit for monorepo, doesn't require conventional commits upfront)
• Add changeset-bot GitHub Action to prompt contributors for changesets on PRs
• Unified versioning to start (frontend/backend tightly coupled), split later if needed

Phase 2 — Commit conventions

• Add commitlint with @commitlint/config-conventional
• Add commit-msg husky hook to enforce conventional commits
• Document commit format expectations for contributors

Phase 3 — Automated releases

• GitHub Action to create version PRs from accumulated changesets
• Auto-generate CHANGELOG per package

Phase 4 — Deploy integration

• Wire semver tags into AWS ECS deploy workflows (replace git SHA tagging)
• Tag Docker images with semver in addition to SHA

Resources/Instructions

• https://semver.org
• https://github.com/changesets/changesets
• https://commitlint.js.org
• https://github.com/conventional-changelog/commitlint