[mikomiel]

🤖 I have created a release beep boop

0.1.0 (2026-11-13)

Features

• pve: extract authorization foundation and align GitHub tooling (e76d605)
• pve: extract authorization foundation and GitHub baseline (db31577)
• pve: extract WebAuthn approval service and notifications (f6d85ca)
• pve: extract WebAuthn approval service and notifications (9c91ae7)

Bug Fixes

• pve: enforce fresh deadlines across locked state transitions (41e59e0)
• pve: guard authority at the SQLite commit boundary (9d28355)
• pve: keep approval data outside executable script context (533ee21)
• pve: revalidate certificate deadlines under the issuance lock (672aeae)

---

This PR was generated with Release Please. See documentation.

[ecomwizards-gandalf]

Independent snapshot review of f8a766accbf7...b873efee2540 in mikomiel/privilege-broker by pi on codex-lb (gpt-6.1-sol).

Verdict: REQUEST_CHANGES

Reviewer output

Findings

P2 — Release version bump leaves the lockfile stale

Location: pyproject.toml:7; corresponding stale entry at uv.lock:447–450.

The project and release manifest now declare 0.1.0, but the editable root package in uv.lock still declares 0.0.0.

This leaves the release checkout inconsistent with its committed lockfile: lock-validating operations such as uv sync --locked reject a lockfile requiring an update, while ordinary uv run commands can update it implicitly. CI’s initial uv sync --frozen skips that freshness validation, so it does not establish that the committed lock matches the release metadata.

Regenerate and commit uv.lock with the version bump, preserving the existing dependency pins. This is part of the smallest complete release change.

Optional suggestions

• Add a lockfile freshness check so future automated release PRs cannot leave project metadata and uv.lock inconsistent.
• Reword docs/releases.md:5–6, which still describes the local metadata version as 0.0.0. Retain the separate publication gate: this PR does not authorize publishing artifacts.

Review scope and limitations

• Read the complete supplied diff and all three changed files, plus relevant release configuration, workflows, repository standards, security documentation, scaffold tests, and the root-package lock entry.
• The PR title follows Conventional Commits. The diff changes no runtime trust boundary, dependency requirements, or tests, and contains no apparent secret values.
• Not run: tests, lint, builds, lock validation, or secret scanners; no command-execution tool was available. The lockfile finding is based on source inspection, not an observed command failure.
• No requested file was unreadable after resolving the repository location. Unchanged runtime code and tests were not exhaustively reviewed; linked commits and historical release-note claims were not independently verified.

VERDICT: REQUEST_CHANGES

Evidence: not written. This review is evidence, not merge authorization.