Prepare 0.2.0

[johncarpenter]

Summary

Release preparation for 0.2.0. No functional change — this is the version bump, the documentation stamp sweep it forces, a changelog, and one README correction.

Cutting the release requires this to land first, because 0.1.0 is already on PyPI and PyPI rejects re-uploads permanently. Publishing a GitHub Release without bumping would build kgmd-0.1.0 and fail the upload.

Changes

Version

• kgmd/__init__.py → 0.2.0, the single source hatchling reads (pyproject.toml declares dynamic = ["version"]). Verified by building: kgmd-0.2.0-py3-none-any.whl.

Documentation stamps — the reason this is a PR and not a one-line commit

• All 16 pages under docs/ move to > Applies to kgmd 0.2.x on line 2. tests/test_docs.py::test_version_stamps compares that stamp against kgmd.__version__, so crossing a minor boundary turns the suite red until every page is walked. That is the intended design, documented at docs/contributing/release.md:37-40.
• Eleven prose references to 0.1.0 / 0.1.x updated. Four describe the broken reset command and the absent migration path — those statements are still true, so they now name 0.2.0 rather than implying a version where the behaviour was fixed.

Upgrade note added

docs/guides/maintenance.md → "Upgrading kgmd" now states what this release actually does to an existing corpus: the schema is untouched and PRAGMA user_version is still 1, so a 0.1.x database opens as-is with no migration — but the first build after upgrading reconciles the graph against the corpus and removes documents whose files are gone. On a corpus with a long edit history that can be a large one-off removal, so it points at kgmd build --dry-run first.

Bumping the version while leaving the upgrade page silent about a destructive behaviour change would have been the wrong kind of quiet.

CHANGELOG.md added

Linked from the README documentation table. The 0.2.0 entry records known issues alongside the additions — the reset defects and the extract --force mention-vector corruption tracked in #4, and the orphan entities the new sweep deliberately does not collect — so the release does not read as though the graph now cleans itself up completely.

README correction

README.md:91 pointed the development clone at github.com/2lines/kgmd, which does not exist. README is the PyPI landing page, so that URL ships to every visitor. PyPI currently renders the 0.1.0 README, so publishing 0.2.0 is what refreshes it.

Testing

• Unit tests added/updated — none needed; no behaviour change
• Integration tests added/updated — none needed
• Manual testing completed — python -m build produces kgmd-0.2.0-py3-none-any.whl, confirming the bump propagates through hatchling
• All tests passing — 135 passed, make format and make lint clean

0.2.0 does not exist on PyPI (only 0.1.0), so the version is free.

Related issues

• Ships the work from Add a .kgmdignore file to exclude paths from indexing #3 (PR Add .kgmdignore exclusions and remove files that leave the corpus #5).
• Known issues in the changelog reference Destructive paths leave stale vectors and orphan entities behind #4.
• Not affected by Document openai/anthropic/openrouter/ollama explicitly and default to local ollama #6.

This repo does not use Jira or Linear.

Additional Notes

• No code change. The only non-documentation file touched is kgmd/__init__.py.
• No migration. Schema unchanged, PRAGMA user_version still 1.
• Merging this does not publish anything. .github/workflows/publish.yml triggers only on release: types: [published] — there is no workflow_dispatch, so the workflow cannot be started from the Actions tab. Publishing a GitHub Release is the trigger.

After merge, to actually release

git switch main && git pull
gh release create v0.2.0 --target main --title "v0.2.0" --notes-file <(sed -n '/^## 0.2.0/,/^## 0.1.0/p' CHANGELOG.md | sed '$d')

That fires publish.yml, which builds in the pypi environment and uploads via OIDC trusted publishing. The path is proven — 0.1.0 shipped through it.

Pre-release checklist is not satisfied by this PR

docs/contributing/release.md:86-114 requires manual verification that CI structurally cannot do, and it is marked not optional:

• The quickstart and all three docs/examples/ walkthroughs executed end to end — needs a provider credential and real spend.
• kgmd mcp round-tripped from a real assistant client.
• pip install kgmd in a clean virtualenv, including the loadable-SQLite-extension caveat.
• The Windows global config path %LOCALAPPDATA%\kgmd\kgmd\config.yaml — this box has never been tickable. The page states the path was derived from platformdirs source and has never been executed on Windows, and that the configuration reference must keep saying so until it is. Treat it as a standing caveat, not a blocker.
• Onboarding and contributor-setup timings — no baseline exists yet; this release could establish one.

[greptile-apps]

Greptile Summary

The PR prepares the 0.2.0 release without changing application behavior.

• Bumps the package version from 0.1.0 to 0.2.0.
• Updates all documentation version stamps and release-specific references.
• Adds a changelog and upgrade guidance covering reconciliation behavior and known issues.
• Corrects the README repository URL and links the release history.

Confidence Score: 5/5

The PR appears safe to merge; the version source, documentation stamps, links, and release guidance are internally consistent.

The package build reads the updated version directly from kgmd/__init__.py, every discovered documentation page carries the matching 0.2.x stamp, and the newly documented operational behavior agrees with the current implementation.

_{Reviews (1): Last reviewed commit: "Prepare 0.2.0" | Re-trigger Greptile}