Context

The ground-state molecular-energy tutorial introduced in #604 is intentionally pinned to a published QDK/Chemistry version through docs/source/tutorials/_versions.py. Its prose, numerical outputs, notebooks, completed lab reference, and regression tests can all be version-specific. Other documentation may also contain version-specific API names, behavior, numerical examples, or workflow assumptions.

Ordinary development changes on main should not require immediate documentation baseline updates. However, when a new QDK/Chemistry release is published, we need a reliable reminder to evaluate and update version-specific documentation against that released package.

Idea

Add a low-priority release watcher that:

• Runs on GitHub release.published, not on ordinary pushes to main.
• Ignores prereleases unless explicitly requested.
• Compares the published release tag with versions declared for version-specific documentation, initially GROUND_STATE_TUTORIAL_VERSION.
• Opens a deduplicated maintenance issue when a published release is newer than a documented compatibility target.
• Optionally runs on a schedule as a fallback in case a release event is missed.
• Does not automatically bump documentation version pins, because that would claim compatibility before scientific and editorial validation.

The generated maintenance issue could include a checklist to:

• Install the published wheel in a clean environment.
• Run affected scripts and notebooks on supported platforms.
• Review changed APIs, scientific behavior, numerical outputs, and resource/runtime claims.
• Update version pins, prose, example outputs, completed references, and tests where appropriate.
• Run documentation review, pre-commit, and compatibility validation before publishing the update.

This could start with the QPE tutorial and later use a small registry of documentation artifacts that intentionally target specific package versions.

Questions

@wavefunction91, what do you think of this approach? In particular:

• Does release.published align with the project's actual package release process?
• Would an automatically opened maintenance issue be preferable to an automated draft PR?
• Are there other version-specific documentation surfaces that should be tracked from the start?

This is intentionally low priority; the immediate goal is to avoid relying on someone remembering to revisit version-specific documentation after each release.