chore: release 0.2.1

[steipete]

Prepare ordercli v0.2.1, the first patch release with macOS downloads signed using Peter Steinberger's Developer ID and notarized by Apple.

Finalize the September 14 changelog section with the signing highlight and bump the CLI's built-in version to 0.2.1. The shared workflow migration is already merged in #12; publication will be dispatched only after this PR and its exact merged commit pass CI.

Validation: release metadata and extracted notes; Go build, full tests and lint; independent review through P2. The six-target release build and Docker smoke were verified during the migration and run again in PR CI.

[clawsweeper]

🦞👀
ClawSweeper picked this up.

Pull request received. I will update this pull request when review starts.

ClawSweeper review complete

ClawSweeper finished reviewing this revision. The review result is being finalized.

View the workflow run.

[clawsweeper]

Codex review: needs maintainer review before merge. Reviewed September 14, 2026, 11:25 AM ET / 15:25 UTC.

ClawSweeper review

What this changes

Finalizes the 0.2.1 changelog with the macOS signing highlight and updates the CLI’s built-in version to 0.2.1.

Merge readiness

✅ Ready for maintainer review

The release preparation remains necessary: main still reports 0.2.0, and the latest published release is v0.2.0. No introduced defects were found; repository policy and OWNER authorship also preclude automatic closure.

Priority: P3
Reviewed head: b41007dac4ae53f7a36a1b4919f1c86fb876aab7

Review scores

Measure	Result	What it means
Overall readiness	🐚 platinum hermit (4/6)	A focused, consistent release update with no actionable defects found.
Proof confidence	🌊 off-meta tidepool	Not applicable: The OWNER-authored PR is exempt from contributor runtime proof; its introduced behavior is release metadata and version identification, with no authority-boundary change.
Patch quality	🐚 platinum hermit (4/6)	No actionable review findings were identified.

Verification

Check	Result	Evidence
Real behavior	Not applicable	Not applicable: The OWNER-authored PR is exempt from contributor runtime proof; its introduced behavior is release metadata and version identification, with no authority-boundary change.
Evidence reviewed	6 items	Verified introduced scope: The pinned base-to-head diff changes only the changelog heading/highlight and the version constant. Release process alignment: The release checklist explicitly calls for updating the version constant and finalizing the changelog before landing; publication follows successful checks on the merged commit. The metadata checker accepts the matching 0.2.1 values by inspection. Current main still needs the version bump: The fetched main revision retains Version = "0.2.0".
Findings	None	None.
Security	None	None.

How this fits together

The version constant feeds CLI version output and provider request identification. The finalized changelog and version are checked together before the existing release workflow publishes binaries.

flowchart LR
  A[Version constant] --> B[CLI version output]
  A --> C[Release metadata check]
  D[Finalized changelog] --> C
  E[Requested release version] --> C
  C --> F[Existing publication workflow]

Loading

Before merge

None.

Agent review details

Security

None.

Review metrics

None.

Technical review

Best possible solution:

Keep the matching release metadata and use the documented publication process after the merged commit passes its required checks.

Do we have a high-confidence way to reproduce the issue?

Not applicable: this PR prepares release metadata rather than reporting a runtime defect.

Is this the best way to solve the issue?

Yes: the two-file update follows the existing release checklist and preserves the established version and changelog sources.

AGENTS.md: found and applied where relevant.

Codex review notes: model internal, reasoning medium; reviewed against acb1b0590c63.

Labels

Label changes:

• add P3: This is a narrow release metadata update; the signing implementation already landed separately.
• add rating: 🐚 platinum hermit: Overall readiness is 🐚 platinum hermit; proof is 🌊 off-meta tidepool and patch quality is 🐚 platinum hermit.
• add status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Not applicable: The OWNER-authored PR is exempt from contributor runtime proof; its introduced behavior is release metadata and version identification, with no authority-boundary change.

Label justifications:

• P3: This is a narrow release metadata update; the signing implementation already landed separately.
• rating: 🐚 platinum hermit: Overall readiness is 🐚 platinum hermit; proof is 🌊 off-meta tidepool and patch quality is 🐚 platinum hermit.
• status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Not applicable: The OWNER-authored PR is exempt from contributor runtime proof; its introduced behavior is release metadata and version identification, with no authority-boundary change.

Evidence

What I checked:

• Verified introduced scope: The pinned base-to-head diff changes only the changelog heading/highlight and the version constant. (internal/version/version.go:3, b41007dac4ae)
• Release process alignment: The release checklist explicitly calls for updating the version constant and finalizing the changelog before landing; publication follows successful checks on the merged commit. The metadata checker accepts the matching 0.2.1 values by inspection. (docs/RELEASING.md:16, b41007dac4ae)
• Current main still needs the version bump: The fetched main revision retains Version = "0.2.0". (internal/version/version.go:3, acb1b0590c63)
• Published release: GitHub identifies v0.2.0 as the latest published release; local tags likewise contain v0.1.0 and v0.2.0.
• Merged prerequisite and historical routing: GitHub verifies fix: sign and notarize macOS release binaries #12 merged at acb1b05. Commit API inspection attributes that changelog addition and the earlier 0.2.0 version update to steipete. Local deeper blame/show traversal encountered unavailable historical objects; GitHub commit patches supplied the relevant history. (CHANGELOG.md:7, acb1b0590c63)
• Validation boundary: Existing CLI coverage checks version output against the constant and verifies that version queries preserve configuration. Supplied checks show both Go test jobs, lint, and Docker passing, with the macOS release job still running. No builds or tests were executed during this read-only review. (internal/cli/run_func_test.go:21, b41007dac4ae)

Likely related people:

• steipete: Suggested for follow-up; no historical authorship or introduction is verified. (role: unverified routing candidate; confidence: low)

Rating scale

Score	Internal tier	Crab rank	Meaning
6/6	S	🦀 challenger crab	Exceptional readiness
5/6	A	🦞 diamond lobster	Very strong readiness
4/6	B	🐚 platinum hermit	Good normal PR; ordinary maintainer review
3/6	C	🦐 gold shrimp	Useful, but confidence is limited
2/6	D	🦪 silver shellfish	Proof or implementation needs work
1/6	F	🧂 unranked krab	Not merge-ready
N/A	NA	🌊 off-meta tidepool	Rating does not apply

Overall follows the weaker of proof and patch quality.
Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

Workflow

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.