Define CI and checks picker action gating rules #182

New issue

Closed

opened 2026-04-12 19:29:29 +00:00 by barrettruth · 1 comment

barrettruth commented

2026-04-12 19:29:29 +00:00

Problem

The CI and checks pickers expose actions like log, watch, browse, and filters, but the rules for when those actions are actually valid are still ad hoc.

Examples already seen in practice include skipped checks where log fails, forge-specific summary behavior, and actions that stay visible even when they only produce message-area diagnostics.

Expected

Define explicit action gating rules for CI and check entries.

That should cover at least:

when log is available
when watch is available
when browse is preferable to log
whether invalid actions are hidden or disabled
how status-specific entries (skipped, pending, cancelled) should present their available actions

Notes

This is separate from broader CI readability and summary UX work. The focus here is action validity and picker behavior.

## Problem The CI and checks pickers expose actions like `log`, `watch`, `browse`, and filters, but the rules for when those actions are actually valid are still ad hoc. Examples already seen in practice include skipped checks where `log` fails, forge-specific summary behavior, and actions that stay visible even when they only produce message-area diagnostics. ## Expected Define explicit action gating rules for CI and check entries. That should cover at least: - when `log` is available - when `watch` is available - when `browse` is preferable to `log` - whether invalid actions are hidden or disabled - how status-specific entries (skipped, pending, cancelled) should present their available actions ## Notes This is separate from broader CI readability and summary UX work. The focus here is action validity and picker behavior.

barrettruth commented

2026-04-12 21:39:28 +00:00

Closing this because the product direction is to keep picker actions flat rather than introduce per-entry CI/check action gating. Any remaining CI/check UX problems should be tracked as narrower feedback, browse/log behavior, or refresh bugs instead.