version-release

# Version Release Use Semantic Versioning as the repository-wide release rule: - **Patch** (`X.Y.Z+1`) for backward-compatible bug fixes, documentation-only changes, dependency/security maintenance, internal refactors, and small user-visible improvements that do not create a substantial new capability. - **Minor** (`X.Y+1.0`) for backward-compatible feature additions or meaningfully larger product capabilities, including new workflows, pages, integrations, API fields/routes, or major UX surfaces. - **Major** (`X+1.0.0`) for backward-incompatible behavior, removed/renamed public contracts, required migrations, or fundamental product/architecture changes. When a change fits more than one category, use the highest applicable bump. When uncertain between adjacent categories, prefer the higher bump or ask the user before releasing. Never infer the bump from commit count, diff size, or elapsed time alone. When the user explicitly requests a concrete version, that instruction overrides automatic classification. State the override and synchronize the requested version exactly. ## CCAM release workflow 1. Read the current root `package.json` version and summarize why the change is patch, minor, or major. 2. Update the root `package.json` and root lockfile. 3. Mirror the shipping version in `desktop/package.json` and `desktop/package-lock.json`. 4. Update the OpenAPI version example in `server/openapi.js`, then run `npm run openapi:yaml`. 5. Update the deployment surface, which ca...