Skip to content

Add fail-open, non-destructive finding publication controls to the reusable Action #478

Description

@acoliver

Problem statement

OpenCodeReview emits structured category and severity for each finding, but the reusable GitHub Action does not render or use those fields when publishing review comments. Every line-addressable finding is treated as an inline candidate regardless of category/severity, while downstream users must either post everything or write a custom publication pipeline.

Released v1.7.15 evidence:

Production evidence from https://github.com/vybestack/llxprt-code/actions/runs/29946076923:

  • 75 raw findings;
  • 4 high, 37 medium, 33 low, and 1 undocumented info severity;
  • 13 bug, 15 undocumented correctness, 31 maintainability, 12 test, 3 security, and 1 other category.

After exact deduplication, a conservative presentation policy that moved only low maintainability/test/style/documentation and info-like findings to a collapsed summary would have reduced inline candidates from 74 to 46 while preserving every finding. This is evidence of the need for publication routing, not a proposal to make that exact policy the upstream default.

The key requirement is non-destructive, fail-open control. Category and severity are model-generated metadata, not calibrated truth, and unknown values already occur in real output. Filtering must never silently discard malformed or lower-tier findings.

Proposed solution

Add neutral, opt-in publication controls to the reusable GitHub Action.

Rendering

  • Render category and severity labels for inline and summary findings.
  • Make missing/unknown values explicit instead of omitting them.

Routing

Allow callers to configure deterministic routing by category/severity to destinations such as:

  • inline review comment;
  • sticky summary;
  • artifact/raw output only when explicitly allowed;
  • overflow summary.

Defaults should preserve existing behavior and fail open. Missing, unknown, or malformed metadata must remain visible unless a caller explicitly selects a different policy.

Preservation and accounting

  • Preserve every raw finding and original metadata in machine-readable output.
  • Record the destination and reason for every finding.
  • Expose mutually exclusive counts for raw, exact duplicate, overlap-suppressed, policy-routed-inline, policy-routed-summary, overflow, failed, and unknown-schema findings.
  • Ensure the sum of terminal destinations reconciles with raw input.
  • Never call a summary-routed finding deleted or resolved.

Safety and evaluation

  • Keep policy separate from finding generation and severity assignment.
  • Do not ship an upstream opinion that low means unimportant.
  • Document that consumers should shadow-evaluate policies against their own labeled review corpus before suppressing inline visibility.
  • Integrate with parser-boundary schema validation so malformed values fail open.

Alternatives considered

Project-specific custom posting script

This works, but duplicates parsing, review-comment anchoring, sticky summaries, retry behavior, and ambiguous-write reconciliation already owned by the reusable Action. The Action should provide neutral mechanics while projects choose policy.

Tighten review rules only

Project rules can reduce low-value generation, but they trade recall for precision and do not provide deterministic presentation or audit accounting. Generation guidance and publication routing solve different problems.

Drop all low-severity comments

This is unsafe because severity is model-assigned and not calibrated. Non-destructive routing to summary/artifact preserves review evidence while reducing inline noise.

Reuse overlap-based incremental suppression

Overlap suppression addresses repeated location publication. It does not route findings based on structured metadata or preserve explicit policy reasons.

Affected area

  • Output / Formatting
  • Configuration
  • Telemetry / Observability
  • Other: reusable GitHub Action

Additional context

This request intentionally does not include a finding-confidence field. Confidence semantics should be grounded in evaluation evidence before becoming another model-generated control signal.

Related work:

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions