Latest v0.7.1 release lacks the unattended auto workflow marked shipped in #511

[MongLong0214]

What is inconsistent

Issue #511 was closed as completed with the statement that unattended capture had shipped in v0.7.1, including commitlore auto on|off|status.

The published v0.7.1 release does not contain that implementation:

• Release v0.7.1 was published on 2026-08-09 from 12379345a3d57117d9b2f841754c9c675624925c.
• PR Let a repository say capture may stop asking #517 (unattended capture) merged into dev on 2026-08-11 as 3ed68c58906d9c26ce6854c4f740b21f67cb0a7f.
• PR Ask once at install about capture with nobody in the loop #519 (the auto switch/init prompt) merged into dev on 2026-08-11 as 2452a630042d65fb334dce7b21850a31e289a945.

Reproduction

With the latest published release installed:

$ commitlore --version
0.7.1

$ commitlore --help
# no `auto` command

$ commitlore capture --help
# no `--unattended` option

A repository can contain .commitlore-policy.json with mode: "auto" and unattended: true, while the latest release has no command or capture option that exposes the shipped unattended workflow.

Building current dev at 78f88be16413796845794d70465f60d7b919fe3f restores both surfaces:

commitlore auto status
unattended capture: on

commitlore capture --help
--unattended

The focused auto/init/prepare/post-commit tests pass on that head (44 tests across the relevant files).

Expected

One of the following should make the release state truthful and discoverable:

1. Publish a release containing Let a repository say capture may stop asking #517 and Ask once at install about capture with nobody in the loop #519, then update M-UX: capture leaves the user's workflow #511's completion reference; or
2. Reopen/relabel M-UX: capture leaves the user's workflow #511 as merged-to-dev but unreleased.

Until then, the latest release should not be described as having shipped unattended capture.

[MongLong0214]

Confirmed, and #511 is reopened as merged-to-dev, unreleased.

v0.7.1 = 12379345a3d5   ->  src/commands/auto.ts absent
dev                     ->  present

Your option 2. A release containing #517 and #519 is queued behind the CDEB work in flight; when it lands, #511 closes against the tag that actually carries it rather than the one that preceded it.

Keeping this open until then, since it is the record of why the release note was wrong.

[MongLong0214]

Resolved as of v0.8.0 and still true in v0.8.1.

The inconsistency was real: v0.7.1 was credited with unattended capture that merged two days after it was published. v0.8.0 was the release that actually carried it, and the CHANGELOG says so in those terms rather than pretending otherwise.

Verified against the published tag rather than the working tree:

$ git ls-tree -r --name-only v0.8.1 | grep -i auto
commands/auto.md
dist/commands/auto.js
dist/commands/doctor/checks/capture-unattended-initiator.js

$ commitlore auto --help
Usage: commitlore auto [options] [command]
read and write the unattended-capture setting (.commitlore-policy.json)

Closing the bookkeeping half. The separate question of whether unattended capture actually initiates in practice is #527, which stays open — see the note being added there.