Problem
cppa-cursor-browser has all the release infrastructure in place but has not yet cut an actual tagged release. pyproject.toml already declares version = "0.1.0", CHANGELOG.md exists with a detailed [Unreleased] section covering all shipped functionality (Web UI, 6 export formats, CLI export, CLI agent session support, desktop packaging, typed models, CI matrix, Python packaging), README.md documents a semver versioning policy, and docs/API_DEPRECATION.md specifies the full deprecation lifecycle (changelog → CLI help → response headers → server log → removal). The structural improvements being made (service extraction, typed accessors, test investment) have no stable reference point — consumers cannot pin to a known-good state or detect when the API surface shifts. The remaining work is mechanical: promote the [Unreleased] section to [0.1.0] with a date, cut the git tag, and create a GitHub release.
Acceptance Criteria
Implementation Notes
pyproject.toml already has version = "0.1.0" — no edit neededCHANGELOG.md has content under [Unreleased] — rename to [0.1.0] - 2026-06-XX and add empty [Unreleased] aboveREADME.md already has versioning policy; docs/API_DEPRECATION.md already has deprecation lifecycle — no new docs needed- Use
gh release create v0.1.0 --title "v0.1.0" --notes-file - for the GitHub release
- Reduced from 3pt → 2pt: all infrastructure exists, remaining work is tag + release mechanics
References
pyproject.toml:7 — version = "0.1.0" (already set)CHANGELOG.md — [Unreleased] section (ready to promote)docs/API_DEPRECATION.md — deprecation lifecycle policy (already written)README.md:245 — semver versioning policy (already documented)
Problem
cppa-cursor-browser has all the release infrastructure in place but has not yet cut an actual tagged release.
pyproject.tomlalready declaresversion = "0.1.0",CHANGELOG.mdexists with a detailed[Unreleased]section covering all shipped functionality (Web UI, 6 export formats, CLI export, CLI agent session support, desktop packaging, typed models, CI matrix, Python packaging),README.mddocuments a semver versioning policy, anddocs/API_DEPRECATION.mdspecifies the full deprecation lifecycle (changelog → CLI help → response headers → server log → removal). The structural improvements being made (service extraction, typed accessors, test investment) have no stable reference point — consumers cannot pin to a known-good state or detect when the API surface shifts. The remaining work is mechanical: promote the[Unreleased]section to[0.1.0]with a date, cut the git tag, and create a GitHub release.Acceptance Criteria
[Unreleased]section promoted to[0.1.0]with release datev0.1.0created on current maingh release create v0.1.0with brief release notespyproject.tomlversion field is already0.1.0(no change needed)docs/API_DEPRECATION.md(no change needed)Implementation Notes
pyproject.tomlalready hasversion = "0.1.0"— no edit neededCHANGELOG.mdhas content under[Unreleased]— rename to[0.1.0] - 2026-06-XXand add empty[Unreleased]aboveREADME.mdalready has versioning policy;docs/API_DEPRECATION.mdalready has deprecation lifecycle — no new docs neededgh release create v0.1.0 --title "v0.1.0" --notes-file -for the GitHub releaseReferences
pyproject.toml:7—version = "0.1.0"(already set)CHANGELOG.md—[Unreleased]section (ready to promote)docs/API_DEPRECATION.md— deprecation lifecycle policy (already written)README.md:245— semver versioning policy (already documented)