Changelog Automation

This page explains how the public changelog now works after the v1.0.0 reset.

Source Of Truth

The public changelog lives in changeslog/changelog.md on dev branches.

• It is curated as release documentation, not generated from every raw commit
• The published site is the built output under public/docs/
• Production serves only public/docs/, never the raw changeslog/ source

Current Workflow

1. Update changeslog/changelog.md on a local-dev-* branch when release-worthy changes are ready.
2. GitHub rebuilds the public docs output from the VitePress source.
3. The filtered production PR carries only the built docs into main.
4. GitHub Releases provide the deployable ZIPs for production.

Why The Reset Matters

The public changelog is intentionally focused on the v1.0.x release line after the cleanup and production-pipeline reset.

• Legacy v4 and v3 entries are no longer part of the published history
• The public changelog should match the live GitHub release line
• Release notes should describe platform changes, not internal workflow noise

Good Practice

• Write release entries in user-facing language
• Group related changes under a clear release theme
• Keep secret handling, runtime caches, and local-only noise out of the public release story