Add Greptile-style review priorities #6
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "feat/review-priorities"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Summary
Verification
go test ./...go vet ./...sh scripts/adversarial-check.sh/oc review
OpenCode Review
Execution completed for
lambadalambda/opencode-forgejo-botat8dd5ea724ae2(job #37).Rating: 5/5
This PR cleanly introduces review protocol v3 with Greptile-style priorities (p0/p1/p2) replacing the v2 severity field, plus a conservative migration path for persisted v2 results. Fresh submissions now require priority and reject severity; ratings are hard-capped by the worst finding (p0→1, p1→3, p2→4) and findings are stable-sorted by priority. DecodePersistedReviewReport tries the current decoder first, then falls back to a strict legacy decoder that maps critical→p0, high→p1, medium/low→p2, clamps ratings downward, and preserves original finding indices so durable inline-comment markers stay valid during publication recovery. The inline dedup was switched from exact-body matching to marker+bot-username matching, which correctly avoids duplicating comments whose labels changed from [HIGH]/[LOW] to [P0]/[P2]. The launcher now trusts the dispatcher-decoded persisted report instead of re-normalizing, which is safe because recovery re-uses the authoritative stored ResultJSON and ignores the worker-supplied body. Tests cover migration, ordering, rating caps, collapsed-duplicate preservation, and inline identity preservation across pending/submitted legacy reviews. vet/fmt clean; all tests and adversarial checks pass. No correctness, security, data-integrity, or performance defects found.
No findings were reported.
Production-ready. The protocol bump is implemented with a sound, well-tested backward-compatibility strategy: legacy v2 results are migrated only during publication recovery with conservative priority mapping and rating capping, finding indices are preserved to keep durable inline markers stable, and the marker-based dedup correctly handles the severity→priority label change without creating duplicate comments. Fresh submissions are strictly validated (priority-only, exact fields, rating caps enforced as hard rejections). The recovery flow correctly re-uses the authoritative stored ResultJSON and decodes via the persisted decoder at both claim and result boundaries. The change to persistedClaimReport is safe because it only runs in recovery where the dispatcher has already validated the report. The bundled 'Last reviewed commit' rendering is benign and tested. I found no actionable defects.