feat(bugs): support priority in list, show, and a new prioritize command

[tjdammann]

Brings bug priority into the CLI: filtering and sorting on bugs list, priority and its rationale on bugs show, and a new bugs prioritize for overriding Detail's assessment.

Also carries a h2 security bump, folded in from a separate PR — see the last section for why.

detail bugs list

• --priority p1|p2|p3|none — comma-separate or repeat. Applied by the API, so unlike --vulns or --introduced-by it shrinks the fetch instead of forcing a full one.
• --sort newest|oldest|priority — default newest, which is the existing behavior.

none selects bugs Detail never scored. It has to exist: priorities are only assigned at scan time and the feature is recent, so most bugs in an established repo carry no priority — a filter that could only name P1/P2/P3 would silently hide them.

Cards now show a Priority row when the bug has one.

detail bugs show

Adds Priority (with its severity word) and Rationale — Detail's own reasoning, which only the single-bug endpoint returns. If someone has since overridden the score, an Override line reports what Detail originally assigned and why it was changed:

Priority    P1 (High)
Rationale   Causes orphaned devboxes on process shutdown during transitional states…
Override    Detail assigned P2; changed because: urgent bug whoops. whoops.

detail bugs prioritize <BUG_ID>

Sets a priority and records the change on the bug's timeline. Prompts for --priority in a TTY, requires the flag otherwise — same shape as bugs close. --comment is worth passing: it's what a later bugs show reports as the override reason. Re-sending the priority a bug already has reports "no change" rather than implying an edit, because the API writes nothing in that case.

Multi-status ordering

The bugs API takes one status per request, so --status pending,resolved is two calls that get concatenated — each block ordered, the whole not. Before this, that only affected newest; with --sort priority it would have shown every pending bug P1-first and then started over at P1 for the resolved ones. sort_bugs re-applies the ordering to the merged list, using the same rank rules as the server (unscored last, createdAt then id as tiebreakers). Single-status queries skip it — the server already ordered them.

Testing

• 324 lib tests + 18 integration tests pass; cargo fmt --check, cargo clippy -- -D warnings, and cargo check are clean. docs/HELP.md is regenerated and passes its check.
• 9 new unit tests: priority_query casing / dedup / none sentinel / empty selection, and sort_bugs for severity order, tie-breaking, newest-vs-oldest symmetry, and stability across equal timestamps.
• 57-check end-to-end run of the built binary against a local backend carrying the new endpoints, against a database with a real spread of priorities (1 P1, 11 P2, 26 P3, 994 unscored resolved bugs). All 57 passed:
  • Filter — each level singly (1 / 4 / 10), comma-separated (5), the repeated-flag form producing an identical result, a repeated value deduping rather than double-counting, none (994, none scored), level + none (995, both buckets), all three levels (15, none unscored), and an empty match set returning cleanly rather than erroring. --priority p4 is rejected by clap with the valid values listed and never reaches the API.
  • Sort — --sort priority --all returned exactly P1×1, P2×4, P3×10, unscored×994: four clean runs, no interleaving. newest/oldest monotonic in opposite directions, default identical to newest, --sort severity rejected.
  • Multi-status merge (the client-side re-sort) — --status pending,resolved --sort priority came back globally ordered rather than as two per-status blocks, with the total equal to the sum of both statuses; newest and oldest likewise globally monotonic; the paged variant's window is ordered and starts at P1.
  • Composition — --priority holds alongside --all, --vulns, --since, and --sort.
  • Pagination — walked three pages under sort=priority: no duplicates, and the concatenation matches the single-page result exactly.
  • bugs show — priority and rationale present in both JSON and table for a scored bug, both absent for an unscored one (with the rest of the report intact), and the list card showing the bare level while show shows P1 (High).
  • bugs prioritize — set / no-op / JSON / restore, the Override line rendering with the comment, the reprioritized bug moving into its new filter bucket, and the >2000-char comment rejected client-side before any request goes out.
  • Everything it mutated was restored (priority back to P3, audit rows and the test key deleted, verified by query).
• The vendored openapi.json was generated from that local backend, then confirmed byte-identical to what cargo xtask generate-openapi itself produces (ran xtask against the local URL and diffed). So the post-deploy regeneration should be a no-op — if it isn't, the backend spec changed after this branch was cut.

Also included: h2 0.4.17 (RUSTSEC-2026-0258)

cargo audit fails on main with RUSTSEC-2026-0258 — h2 accepts and queues empty DATA frames without limit, so a stream that isn't actively drained can grow memory unboundedly or panic on length overflow. Low severity, denial-of-service category, advisory published 2026-08-17. Produced with cargo update -p h2 (0.4.15 → 0.4.17; the advisory needs ≥ 0.4.16).

h2 is not a direct dependency — it arrives via reqwest → hyper → hyper-rustls, and again through axoupdater → axoasset → reqwest. There is no manifest entry to bump, and bumping reqwest would not help: hyper 1.11.0 declares h2 = "0.4.14", so every 0.4.x at or above 0.4.14 already satisfies it. Only the lockfile was pinning 0.4.15 — which is also exactly what cargo audit reads.

The diff also moves six windows-sys edges from 0.61.2 to 0.52.0. That is expected re-resolution, not collateral damage: rustix and tempfile declare windows-sys = ">=0.52, <0.62", a range satisfied by both, so cargo consolidates them onto 0.52.0 (already in the lockfile), while mio (0.61) and socket2 (>=0.60, <0.62) cannot use 0.52 and stay put. Both versions remain in the tree, as before, and windows-sys is a cfg(windows) target dependency so only the Windows artifact is affected. It reproduces from a clean clone plus cargo update -p h2.

Why it is in this PR rather than its own. It started as a separate PR. main is currently failing two required checks at once — Security Audit (this advisory) and Vendored Artifacts (its vendored openapi.json went stale the moment the priority endpoints deployed). The spec refresh cannot be split from the client code that consumes it: dropping the new openapi.json onto a branch without the updated call sites fails to compile, because the regenerated list_public_bugs takes seven arguments instead of five. So no PR that fixes only one of the two can go green, and the split PR was unmergeable on its own.

[aviator-app]

Current Aviator status

Aviator will automatically update this comment as the status of the PR changes.
Comment /aviator refresh to force Aviator to re-examine your PR (or learn about other /aviator commands).

This PR was merged manually (without Aviator). Merging manually can negatively impact the performance of the queue. Consider using Aviator next time.

---

See the real-time status of this PR on the Aviator webapp.

Use the Aviator Chrome Extension to see the status of your PR within GitHub.

[indent]

Issues

Review closed.

CI Checks

2 CI checks failed on 8e6f8c8.

Security Audit

• Security Audit finished with failure.

Vendored Artifacts

• Vendored Artifacts finished with failure.