feat(action): add fail-open category/severity publication controls (#478)

[nitishagar]

Summary

First increment toward #478 (the full issue is a roadmap). Adds category/severity-aware, fail-open publication controls to the reusable GitHub Action:

1. Render a CLI-consistent [category · severity] badge on every comment that carries metadata (inline and summary), matching buildBadge() in cmd/opencodereview/output.go.
2. One opt-in routing destination: move low-severity and/or selected-category findings from inline comments to the PR summary, via two new action.yml inputs (route_severity_below, route_categories).
3. Fail-open semantics: no finding is ever silently dropped — unknown/malformed metadata on a finding never matches the policy, and a malformed policy itself degrades to no-routing.
4. Accounting reconciliation: a new routed bucket is disjoint from summary/skipped/failed, so destination counts still sum to the raw input total (inline + summary + skipped + failed + routed == total).

With no routing input set, behavior is byte-equivalent to today except for the additive badge prefix on comments that carry category/severity metadata. No Go changes — category/severity already serialize into the Action's input JSON via model.LlmComment.

Key design decisions (invariant → mechanism)

• I1 (fail-open): routeComment requires the finding's own category/severity to be a known enum member before it can match; unknown metadata falls through to the normal inline path (visible). buildPolicy returns a NO_ROUTING sentinel on any malformed input.
• I2 (accounting): new routed bucket + comments_routed output; the partition loop routes each finding into exactly one bucket via mutually-exclusive continue branches.
• I3 (defaults): empty policy = no-op; the badge is an additive prefix that renders "" (no line) when metadata is absent, so metadata-less comments are byte-identical to today.
• I4 (idempotency): routing is a placement decision in the partition loop — routed findings continue before reviewComments.push, so they never enter toSend/toRetry/either createReview call, and carry no idempotency id. No double-post surface on retry.
• I6 (badge consistency): shared buildBadge byte-matches the CLI degeneration. Control-char sanitization is intentionally stricter than the CLI's sanitizeTerminal (strips \t/\n too) to defend the Markdown comment-body layout — a documented divergence that only manifests for malformed model output and is safer (clean enum values match exactly).

At-or-below severity semantics

route_severity_below=low routes only low; route_severity_below=medium routes medium AND low (inclusive at-or-below). The lowest tier is still routable, matching the spec's fail-open intent. Category routing is OR-combined with severity routing (a finding matching either condition routes exactly once).

Test coverage

New tests cover every invariant: badge degeneration + control-char sanitization (I6), fail-open on malformed policy/metadata (I1), accounting reconciliation across mixed buckets (I2), defaults-preserve-behavior (I3), routed findings never reach createReview + carry no idempotency id (I4), severity boundary inclusivity, both-conditions-routes-once, and end-to-end severity/category routing.

All existing tests pass unchanged (no existing fixture carries category/severity, so the additive badge is "" for them).

Validation

• node scripts/github-actions/post-review-comments.test.js → exit 0 (existing + 15 new tests)
• npm run test:github-actions → exit 0 (includes check-translation-sync.test.js)
• node -c syntax check + action.yml YAML parse
• Adversarial implementation + test review (PASS, round 2)
• Security review (1 Medium finding re: Markdown injection dispositioned as pre-existing — comment.content is already rendered unsanitized; the badge introduces no new trust boundary. Noted for a separate repo-wide hardening pass.)
• Manual: trace a 3-finding fixture ({critical inline, low inline, no-line}) with route_severity_below=low → expect critical inline, low summary (routed), no-line summary; counts total=3, inline=1, routed=1, summary=1, skipped=0, failed=0.

Closes #478 (first increment).

[github-actions]

🔍 OpenCodeReview found 1 issue(s) in this PR.

• ✅ Successfully posted inline: 1 comment(s)

[github-actions]

Inconsistent metadata normalization between routeComment and buildBadge

routeComment normalizes metadata with String(...).trim().toLowerCase(), while buildBadge uses sanitizeMetadata(...) which strips control characters (\x00-\x1f, \x7f-\x9f) but does NOT trim or lowercase.

This creates a divergence: if model output contains an embedded control character (e.g., "bug\x01"), routeComment would see "bug\x01" and fail to match the policy (correct fail-open), but buildBadge would strip it to "bug" and render [bug] in the badge. The user sees a clean badge label but the finding wasn't routed despite matching the policy category.

Consider using sanitizeMetadata here as well (followed by .trim().toLowerCase()) so both functions agree on what constitutes a valid category/severity value:

const catRaw = sanitizeMetadata(comment && comment.category).trim().toLowerCase();
const sevRaw = sanitizeMetadata(comment && comment.severity).trim().toLowerCase();

This ensures consistent behavior: if the badge renders [bug], the routing policy also recognizes it as bug.

[lizhengfeng101]

merge conflicts

[nitishagar]

@lizhengfeng101 Resolved conflicts. Please take a look when you get a chance.