Problem
The self-hosted review stack posts a GitHub check named "Gittensory Orb Review Agent", controlled today by a binary `gateCheckMode` (`off`/`enabled`) setting. When a self-host fleet's private global config sets `gate.enabled: true` (the documented baseline in `config/examples/global.gittensory.yml`), every repo in the fleet gets this check posted and, if a maintainer added it to branch protection as a required check, PRs can show "Expected — Waiting for status to be reported" under rate-limit/admission pressure even though the review queue has the work queued and will eventually process it.
There's currently no way to keep the check informational/visible without implying it should block merges, nor a clean way to go fully dark without leaving GitHub branch protection permanently expecting a status that never arrives.
Proposal
Add a 3-state `reviewCheckMode: "required" | "visible" | "disabled"` setting (DB + public `.gittensory.yml` + private per-repo/global config layers — all resolved through the existing shared config schema):
- `required`: current behavior — publish/update the check, suitable for branch-protection required-status use.
- `visible`: publish/update the same check, but purely for UI visibility — never intended to be added as a required branch-protection check.
- `disabled`: never create/update the check-run at all. Reviews, comments, labels, and audit records are unaffected; the autonomous merge/close decision engine already does not depend on the bot's own check-run (it deliberately excludes its own check-runs from the live CI aggregate to avoid a self-deadlock), so auto-merge/close continue working normally in every mode.
Backward compatible: existing `gateCheckMode` DB rows migrate to the equivalent new value (`enabled`→`required`, `off`→`disabled`); new/unconfigured repos default to `disabled` (matching the existing opt-in default). `gateCheckMode` itself stays wired for API back-compat.
Self-host docs will recommend `visible` or `disabled` (not `required`) for high-volume autonomous fleets, with migration notes for maintainers to remove the check from branch-protection required-status lists when switching to `disabled`.
No UI/dashboard changes in scope — config-file and API driven only.
Problem
The self-hosted review stack posts a GitHub check named "Gittensory Orb Review Agent", controlled today by a binary `gateCheckMode` (`off`/`enabled`) setting. When a self-host fleet's private global config sets `gate.enabled: true` (the documented baseline in `config/examples/global.gittensory.yml`), every repo in the fleet gets this check posted and, if a maintainer added it to branch protection as a required check, PRs can show "Expected — Waiting for status to be reported" under rate-limit/admission pressure even though the review queue has the work queued and will eventually process it.
There's currently no way to keep the check informational/visible without implying it should block merges, nor a clean way to go fully dark without leaving GitHub branch protection permanently expecting a status that never arrives.
Proposal
Add a 3-state `reviewCheckMode: "required" | "visible" | "disabled"` setting (DB + public `.gittensory.yml` + private per-repo/global config layers — all resolved through the existing shared config schema):
Backward compatible: existing `gateCheckMode` DB rows migrate to the equivalent new value (`enabled`→`required`, `off`→`disabled`); new/unconfigured repos default to `disabled` (matching the existing opt-in default). `gateCheckMode` itself stays wired for API back-compat.
Self-host docs will recommend `visible` or `disabled` (not `required`) for high-volume autonomous fleets, with migration notes for maintainers to remove the check from branch-protection required-status lists when switching to `disabled`.
No UI/dashboard changes in scope — config-file and API driven only.