ux: inconsistent CI/checks terminology across the plugin #258

New issue

Closed

opened 2026-04-14 20:57:49 +00:00 by barrettruth · 0 comments

barrettruth commented

2026-04-14 20:57:49 +00:00

Across the plugin surface, the same workflow is described with several different terms: ci, CI/CD, checks, runs, and forge-native concepts like pipelines or Actions. The root routes and commands are centered on ci, the repo/current-branch picker is presented as CI, and the PR picker exposes a secondary action named ci that opens a picker titled Checks. That makes the user-facing vocabulary feel unstable even though the underlying workflow is meant to be forge-agnostic.

Because those terms are mixed across commands, picker labels, key/config names, and documentation, it is hard to tell which concepts are intentionally distinct and which are just different names for the same thing. In particular, the current wording blurs the boundary between PR-scoped status information and repo- or branch-scoped execution history, while also leaking forge-specific terminology into a cross-forge UX.

Across the plugin surface, the same workflow is described with several different terms: `ci`, `CI/CD`, checks, runs, and forge-native concepts like pipelines or Actions. The root routes and commands are centered on `ci`, the repo/current-branch picker is presented as CI, and the PR picker exposes a secondary action named `ci` that opens a picker titled Checks. That makes the user-facing vocabulary feel unstable even though the underlying workflow is meant to be forge-agnostic. Because those terms are mixed across commands, picker labels, key/config names, and documentation, it is hard to tell which concepts are intentionally distinct and which are just different names for the same thing. In particular, the current wording blurs the boundary between PR-scoped status information and repo- or branch-scoped execution history, while also leaking forge-specific terminology into a cross-forge UX.